Geekly Articles each Day

本番環境での継続的な統合と配信のためのGitLab CI。 パート1：パイプライン



それで、 GitLab CI ：他に何がわかりますか？ 既に、インストール、ランナーのセットアップ、コマンドの使用、GitLab Flowに関する記事があります。 おそらく、複数のチームが関与する実際のプロジェクトでGitLab CIがどのように使用されるかについての十分な説明がありません。 そして、ソフトウェア開発の現代の世界では、これは真実です。結局のところ、（少なくとも）開発者、テスター、DevOps、およびリリースエンジニアがいます。 私たちは数年間、同様の部門でチームに取り組んできました。 この記事では、GitLab CIの機能を使用および改善する方法について、継続的インテグレーション（CI）を実装および適用し、いくつかのチームのチームにアプリケーション配信（CD）プロセスを適用する方法について説明します。

パイプライン


以前にCIシステムに出会ったことがある場合、パイプラインの概念に精通しています。これは一連のステージ（以下ステージという用語の記事では翻訳「ステージ」を使用）であり 、それぞれにいくつかのタスクがあります（以下、ジョブの記事で-タスク」） 。 コードに変更を加えた瞬間から本番環境にロールアウトするまで、アプリケーションはさまざまなチームの手で交代します-パイプラインでの方法と同様です。 これから「パイプライン」という用語が登場しました（「コンベア」-リテラル翻訳のオプションの1つ） 。 この場合、次のようになります。



使用されるステージの簡単な説明：


注 ：完全に普遍的なものはないため、特定のケースでは、このパイプラインは適切ではない可能性が高く、冗長または単純です。 ただし、この記事の目的は、すべての人に適した唯一の真のオプションを説明することではありません。 目標は、GitLab CIで複数のチームと連携する方法の例と 、そのようなパイプラインを実装する機会があることを示すことです。 この情報に基づいて、独自のGitLab CI構成を開発できます。

どのように使用されますか？


まず、パイプラインの使用という観点から、パイプラインについての話、つまりユーザーストーリーと呼ぶことができるものから始めます。 ここでは、実際には2つのパイプラインさえあります。ブランチ用に短縮され、タグ用に完全です。 そして、これらのシーケンスは次のようになります。

  1. 開発者は、 feature_プレフィックスを持つブランチにアプリケーションコードを配置し、DevOpsエンジニアは、 infra_プレフィックスを持つインフラストラクチャコードをブランチに配置します。 これらのブランチの各git pushは、アプリケーションアセンブリプロセス（ ビルドステージ）と自動テスト（ テストステージ）を起動します。
  2. 次の段階のタスクは自動的には呼び出されませんが、手動で開始するタスク（手動）として定義されます。
  3. ステージング段階で、タスクを実行し、アセンブルおよびテストしたアプリケーションを簡素化された環境にロールアウトできます。 これは、開発者、DevOpsエンジニア、テスターに​​よって実行できます。 同時に、すべてのテストに合格して、テスターの環境に展開する必要があります。
  4. テストに正常に合格し、ステージング環境の1つにロールアウトしたら、テスト環境、DevOpsエンジニア、またはリリースエンジニアのみがアプリケーションを実稼働前にロールアウトできます。
  5. テストに成功した機能が蓄積されると、リリースエンジニアは新しいバージョンを準備し、リポジトリにタグを作成します。 タグのパイプラインは、2つの追加ステージのブランチのパイプラインとは異なります。
  6. アセンブリ、テスト、ロールアウトが成功した後、新しいバージョンの追加の手動テスト、顧客への提示、およびアプリケーションの他の「いじめ」が実稼働前に実行されます。 すべてがうまくいった場合、リリースエンジニアは承認タスクを開始します。 何か問題が発生した場合、リリースエンジニアは非承認タスクを開始します。
  7. 実稼働環境へのアプリケーションのロールアウトは、 実稼働環境へのロールアウトが成功し、 承認タスクが完了した後にのみ可能です。 本番環境へのロールアウトは、リリースエンジニアまたはDevOpsエンジニアがトリガーできます。


パイプラインリリースエンジニアの役割

パイプラインとステージの詳細


ビルド段階のタスクは、アプリケーションをビルドします。 これを行うには、開発-オープンソースユーティリティdapp （その主な機能について読んで、 この記事とビデオを参照）を使用します。これは、増分ビルドを高速化します。 したがって、アセンブリは、従来の「メイン」ブランチ（マスター/開発/プロダクション/リリース）だけでなく、プレフィックスfeature_ （アプリケーションコード）、 infra_ （インフラストラクチャコード）およびタグを持つブランチに対して自動的に開始されます。

2019年9月6日更新： dappプロジェクトの名前がwerfに変更され、コードがGoに書き換えられ、ドキュメントが大幅に改善されました。

次の段階であるステージングは、開発者、DevOpsエンジニア、およびテスター向けの一連の環境です。 ここでは、新しい機能やインフラストラクチャの変更を迅速にテストするために、機能が削減された環境でプレフィックスfeature_およびinfra_を持つブランチからアプリケーションをデプロイするいくつかのタスクが発表されます（アプリケーションビルドコードはアプリケーションリポジトリに格納されます）。

運用前段階と運用段階は、タグでのみ使用できます。 通常、リリースエンジニアがテスト済みブランチからの複数のマージリクエストを受け入れた後、タグがハングします。 一般に、 GitLab Flowを使用すると言うことができますが、 実稼働環境への自動展開がないため、個別のブランチはありませんが、タグが使用されるという唯一の違いがあります。

承認ステージは、 承認と非承認の 2つのタスクです。 1つ目は運用環境に展開する機能を含み、2つ目はオフです。 これらのタスクが存在するため、運用上の問題が発生した場合は、リリースエンジニアの同意を得て、展開がそのように行われたわけではないことがわかります。 ただし、ポイントを奪うことではなく、実稼働環境への直接展開がリリースエンジニア自身ではなく、DevOpsチームによって行われることが多いという事実です。 リリースエンジニアは、 承認タスクを起動することにより、DevOpsチームが本番環境に 「ボタンをクリックする 」ことを許可します。 この段階は、郵便通信または口頭に残る可能性のある表面をもたらすと言えます。

この相互作用スキームは、作業中にうまく現れましたが、実装するために一生懸命に努力しなければなりませんでした。 結局のところ、GitLab CIはすぐに使用できるいくつかの必要なものをサポートしていません...

開発.gitlab-ci.yml


ドキュメントとさまざまな記事を検討した後、説明されているパイプラインステージに対応するこのようなオプション.gitlab-ci.ymlをすばやくスケッチできます 。

stages: - build - testing - staging - preprod - approve - production ## build stage build: stage: build tags: [deploy] script: - echo "Build" ## testing stage test unit: stage: testing tags: [deploy] script: - echo "test unit" test integration: stage: testing tags: [deploy] script: - echo "test integration" test selenium: stage: testing tags: [deploy] script: - echo "test selenium" ## staging stage .staging-deploy: &staging-deploy tags: [deploy] stage: staging when: manual script: - echo $CI_BUILD_NAME deploy to dev-1: <<: *staging-deploy deploy to dev-2: <<: *staging-deploy deploy to devops-1: <<: *staging-deploy deploy to devops-2: <<: *staging-deploy deploy to qa-1: <<: *staging-deploy deploy to qa-2: <<: *staging-deploy ## preprod stage deploy to preprod: stage: preprod tags: [deploy] when: manual script: - echo "deploy to preprod" ## approve stage approve: stage: approve tags: [deploy] when: manual script: - echo "APPROVED" NOT approve: stage: approve tags: [deploy] when: manual script: - echo "NOT APPROVED" ## production stage deploy to production: stage: production tags: [deploy] when: manual script: - echo "deploy to production!"

すべてが非常にシンプルで、ほとんどの場合理解可能です。 次のディレクティブは各タスクに使用されます。


注 ：ランナーは他のCIシステムと同様に、GitLab CIの一部です。 GitLabからタスクを受け取り、 scriptを実行するエージェント。

プレゼンテーション「 次のビルドのコーディング 」のランナーについてのスライド（ⓒ2016 Niek Palm）

ちなみに、あなたはこのブロックに気づきましたか？

 .staging-deploy: &staging-deploy tags: [deploy] stage: staging when: manual script: - echo $CI_BUILD_NAME

共通ブロックを定義し、適切なレベルの適切な場所に接続するYAML形式の機能を示しています。 詳細については、 ドキュメントを参照してください。

パイプラインの説明では、 承認段階と生産段階はタグでのみ使用できると述べています。 .gitlab-ci.ymlこれはonlyディレクティブを使用して実行できます。 パイプラインが作成されるブランチを定義し、 tagsキーワードを使用して、 tagsのパイプラインの作成を有効にできます。 残念ながら、 onlyディレクティブはタスク専用です-ステージを記述するときに指定できません。

したがって、 build 、 testing 、 staging 、 pre-productionの各段階でのタスクは、 infra_ 、 feature_ブランチおよびタグで使用可能であり、次の形式を取ります。

 test unit: stage: testing tags: [deploy] script: - echo "test unit" only: - tags - /^infra_.*$/ - /^feature_.*$/

また、 承認と本番の段階のタスクは、タグでのみ使用でき、次の形式を取ります。

 deploy to production: stage: production tags: [deploy] script: - echo "deploy to production!" only: - tags

完全版では、一般的なブロックでonlyディレクティブが.gitlab-ci.ymlされます（このような.gitlab-ci.yml例はこちらから入手できます ）。

次は？


これについて.gitlab-ci.yml 、説明されている.gitlab-ci.ymlの.gitlab-ci.yml作成.gitlab-ci.yml 。 GitLab CIは、第一にユーザーごとにタスクを分離するためのディレクティブ、第二に他のタスクのステータスに対するタスク実行の依存関係を記述するためのディレクティブを提供しません。 また、個々のユーザーのみが.gitlab-ci.ymlを変更できるようにします。

計画の完全な実装は、GitLabのいくつかのパッチとタスクアーティファクトの使用によってのみ可能になりました。 これについては、記事の次の部分で詳しくお読みください：「 本番環境での継続的な統合と配信のためのGitLab CI。 パート2：困難を克服する 。」

Source: https://habr.com/ru/post/J332712/

More articles:


All Articles