SOAプロジェクトのCI / CDプロセスの設定方法

私たちの会社でCI / CDをセットアップした経験を共有し、同様のプロジェクト構造をお持ちの場合はヒントをお聞きしたいと思います。



誰に、この記事は役に立つかもしれません：

• プロジェクトには、いくつかの個別のアプリケーションリポジトリが含まれています。
• 各リポジトリがテストに合格することを確認する必要があります。
• リポジトリ間のバージョンの互換性を確認する必要があります。
• まだ時間がありませんが、プロジェクトをdockerに転送することを計画してください。
• Ansibleプレイブックをいくつか見たいです。

Docker And Ansibleを使用した継続的配信を強くお勧めします。 私たちはソリューションの開発に基づいていました。

CI / CDのタスク

平均して私たちのプロジェクトの1つは、rest-apiを介して相互作用する4〜5個のリポジトリです。 これがマイクロサービスアーキテクチャと見なされるかどうかは定かではありませんが、これを考慮して、CI / CDに対して次のタスクを設定します。

• 各メインブランチの各リポジトリには、動作する（テスト済みの）コードが必要です。
• 各ブランチと各タグは、プロジェクト内のすべてのリポジトリ間で完全に一貫している必要があります。
• 開発用のリポジトリを完全にまたは個別にローカルにプロジェクトを展開できる必要があります。
• テスト、ステージング、実稼働など、さまざまな環境でプロジェクトを展開できる必要があります。

それでは始めましょう。

CI / CDセットアップ

準備段階

• git-flowに切り替えました。 カスタムvcsワークフローは、「クラシック」と比較して、特に初心者にとって冗長で複雑であることがわかりました。
• 毎週のスプリントは製品の新しいバージョンです。 タスクマネージャーの各タスクは、それがバグであろうと機能であろうと、特定のバージョンに関連付けられます。 スプリントの最後にある各リポジトリには、このバージョンのこのカブで何もしなかった場合でも、新しいバージョンのタグがあります。 例外は、スプリントのためにプロジェクトのリポジトリが変更されていない場合です。
• プール要求を介してのみ、マスターに直接プッシュし、ブランチを開発およびリリースすることを禁止しました。
• Jenkinsでのアセンブリとテストのために、上記のブランチのプールリクエストにフックを掛けました。
• Jenkinsによるテストに成功せず、Code Reviewの承認もなしに、プールリクエストのマージを禁止しました。

CIツールとして、ユニットテストとAPI統合テストを実行するJenkinsを選択しました。



CDツールとして-Ansible + Docker。

最初のステップ、別個のリポジトリーのセットアップ

プロジェクト内の各リポジトリの構造を変更しました。

app |-src |-docker | |-ci | |-develop | |-release |-requirements |-Jenkinsfile |-Makefile
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

プールリクエストに設定されたフックは、Jenkinsにリポジトリのテストが必要であることを伝えます。 JenkinsはJenkinsfileを検索して実行します。 後者は、Makefileコマンドを順番に呼び出して、コンテナを構築してテストします。 Makefileは、。 / docker / ciディレクトリからdocker -composeコマンドを実行します。 Jenkinsfileから直接実行するようにdocker-composeを構成していないのはなぜですか？ すべてのリポジトリの汎用性を維持するため。 すなわち リポジトリが異なるとビルドと実行に異なるdocker-composeコマンドが必要になり、これらの違いはMakefileで設定されます。Jenkinsfileのビルドと実行のインターフェイスは常に同じです。



NB。 記事の最後に、例のあるリポジトリへのリンクがあります。



また、Makefileには、開発モードでリポジトリをローカルでアセンブルおよび起動するためのコマンドがあります-ホストマシンからDockerへのソースの転送が構成されており、新しい変更を確認するためにmakeコマンドを使用して行う必要があるのは、docker-composeのみです。 Makefile + ./docker/developがこれを担当します。



./docker/releaseには、テスト/ステージング環境などのリポジトリアセンブリ設定があります。設定は後で使用されます。

2番目のステップ。 追加のdevopsリポジトリーのセットアップ

一般的なリポジトリの目的は、プロジェクトに含まれるリポジトリを展開するときにプロジェクトの整合性を保持することと、統合テストの可能性を維持することです。



リポジトリ構造

 devops |-ansible | |-plays | |-roles |-projects | |-project_1 | | |-apps | | | |-app_1 | | | |-app_2 | | | |-app_3 | | | |-... | | |-docker | | | |-ci-api | | | |-ci-selenium-gherkin | | | |-develop | | | |-testing | | | |-staging | | | |-production | | |-Makefile |-requirements |-Jenkinsfile |-Makefile
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

まず、このリポジトリが統合テストを実行する方法。

最も簡単なことではありませんが、私は説明しようとします。

アプリケーションのあるリポジトリの場合と同様に、プールリクエスト中にビルドおよびテストコマンドを実行するJenkinsfileおよびMakefileファイルがあります。 ビルド設定は./projects/PROJECT/docker/ci-apiにあります。「PROJECT」は現在のプロジェクトの名前です。 アセンブリには、目的のブランチ/タグ内の各リポジトリのクローン作成、apiテスターコンテナの起動が含まれます。



「必要なブランチ/タグ」は、すべてのリポジトリの一般的なブランチ（マスター、開発、リリース）、またはプロジェクトのタグバージョンのいずれかをテストしようとしています。 タグは各リポジトリに配置する必要があります。 次に、「必要な」ものと一致する名前でdevopsリポジトリーにブランチを作成します。 その後、プールリクエストを行うことができます。



Jenkinsは、選択したタグ/ブランチによってプロジェクトをビルドしようとします。リポジトリにリポジトリがない場合、テストは失敗します。 プロジェクトの組み立てに成功すると、「テストフレームワーク」が起動します。このテストフレームワークでは、Postmanとそのユーティリティをコマンドライン（Newman）に使用します。 テストが成功した場合-出力で、プールリクエストをマージし、テスト済みのタグをdevopsリポジトリに配置します。 このタグの存在は、プロジェクトのこのバージョンがテストされていることを示しています。



Postmanテストを実行するには、 コマンドコンテナーに挿入される共有コレクションへのリンクが必要です。



これが唯一のタイプの統合テストですが、少し後でgherkinまたはseleniumによるテストを追加します。少なくともdocker / ci-selenium-gherkinディレクトリはすでに存在します。



次に、このリポジトリのCD機能について説明します。

ここで、. /ansibleには、画像全体を組み立てて異なるサーバーや環境に配信するためのプロジェクト全体のコントロールパネルがあります。

• developer.yml-プロジェクト全体をローカルにデプロイするための設定。
• make-images.yml-特定のバージョンのプロジェクトでdockerイメージを作成し、dockerレジストリにプッシュします。
• deploy-and-run-images.yml-異なる環境のサーバーへのプロジェクトの展開。

各段落の先頭には、このスクリプトを実行するプレイブックがあります。



これらはコマンドによって開始されます：

 $ ansible-playbook -i ../testing.ini make-images.yml -e 'project=todo ver=2017.1'  - -i ../testing.ini --  inventory,       ,        - make-images-yml -- playbook - -e 'project=todo ver=2017.1' --  ,   playbook,       .
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

./ansible/plays/group_vars/all.ymlにはプロジェクト設定があります：

• このプロジェクトに属するリポジトリ。
• どのdocker-registryを使用するか、どのログインパスワードを使用するか。
• 環境ごとの個別設定など

ご覧のとおり、このリポジトリは完全に1つのプロジェクト専用ですが、プロジェクト名をプレイブックのパラメーターに渡し、プロジェクトディレクトリはプロジェクトディレクトリにあります。 これは、このdevopsリポジトリがmaster-devopsリポジトリからのフォークであり、他のプロジェクトのdevopsリポジトリもフォークされているという事実によるものです。 また、同様の構造により、何かを壊すリスクなしに、マスターフォーク間およびフォーク自体の間で一般的な設定と無効なコマンドのコードを交換できます。 より正確には、ansibleディレクトリは共有され、そのリファクタリングはマスターからフォークへ、またはその逆に簡単に転送できます。 また、すべてのプライベートプロジェクト設定は、プロジェクト内の個別のディレクトリにあります。 マスターまたは隣接するdevopsリポジトリからのプールは、現在のプールと競合しません。



Dockerfileが配置されているアプリケーションのdocker / releaseディレクトリに戻ります。このディレクトリは、テスト/ステージングおよび実稼働環境のアセンブリを担当します。 開発以外のすべてのために。 1つのリポジトリのリリースアセンブリだけでは、他のプロジェクトリポジトリと組み合わせた場合にのみ、有用なものは提供されません。 Ansibleは、develop-buildの場合は各プロジェクトのdocker / developerディレクトリから、Dockerfileはリリース環境のビルド（ docker / releaseディレクトリ）から取得するように構成されています。



合計、私たちは何とかすることができました：

• リポジトリのクローンを作成し、開発バージョンを実行する機能
• 各リポジトリはJenkinsによってチェックされます。
• 一般バージョンに従って、すべてのリポジトリにわたって統合テストを実行する共通リポジトリがあります。
• ansibleプレイブック：ローカルに展開し、すべてのプロジェクトリポジトリを開発モードで起動します。
• ansibleプレイブック：選択された環境スキームに応じて画像を収集し、それをdocker-registryに送信します。
• ansibleプレイブック：サーバー上でプロジェクトを構成します。
• ansibleプレイブック：サーバー上でアプリケーションを起動します。

システムを実証するアプリケーションへのリンク：

• todo_todo-todobackend.comプロジェクトからのフォーク。 構造を変更し、テストを追加しました。 todo'shkを作成します。
• todo_crm-ユーザーを作成し、todo_todoにリクエストを送信し、todoを作成してユーザーにバインドします。
• todo_ops-設定を含むdevopsリポジトリ