スケーラブルCI／CD流れのためのヒントとトリック

あなたがプロジェクトを計画するとき、あなたは常にそれが終わりまでにどれくらい大きいかについて、わかりません.したがって、開発プロセスをできるだけスムーズにするガイドラインに従うことは重要です.つの特に有用なツールは、連続的な統合/配信フロー、またはCI/CDの流れです.
プロジェクトの準備が完了する前に、典型的な開発プロセスの開始時に、CIフローは次のようになります.

開発段階では、以下の画像のようになるまでプロセスに追加されます.しかし、いくつかのプロジェクトではこれより多くのステップを見ることができます.Original image .

この記事では、私は典型的なCI/CDの流れを実証し、より大きなプロジェクトのためにこれをスケールするのに役立つヒントを提供します.これらの勧告は、KubernetesのようなDockerやオーケストレーションツールを使用してインフラ設定を開発しているという仮定に基づいています.

VCSフローを定義

すべての近代的なCIツールは、バージョン管理システムに依存しますので、適切なバージョン管理フローを持つ必要があります高いレベルであなたのCIフローを維持する.あなたがアイデアを探しているなら、私はGit FlowまたはGithub Flowをお勧めします.つを選択し、あなたのニーズに応じてパイプラインを適応.
勧告

任意の枝の各プッシュでテストを実行します.これは、あなたの開発者がバグを速く見つけて、コードレビュープロセスをスピードアップするのを助けます.

Dockerイメージビルドプロセスをトリガーして、上記のイメージに示すように展開する分岐を定義します.

あなたのリリースが複雑な手動承認プロセスを持つならば、生産リリースを誘発するために、タグを使用してください.

環境設定

一度Gitの流れがある場合は、ビルドのロジックと統合し、あなたが持っている環境の数に適応します.まず最初に、ローカル環境テストの後、すべてを生産に展開します.後で、開発、uat、および生産を行うことを決めるかもしれません.
例:
マスターブランチを使用して開発環境への展開を開始します.次に、マスターブランチをリリースブランチにマージします.これはUATへの展開を引き起こします.そこで、我々は少数のユーザーに新しいバージョンをテストするのを許します.すべてが正しく動作し、QAチームがリリースを確認した場合、リリースブランチからタグを作成します.

通知を設定する

あなたが好む通知チャンネルを介してすべてのCIフロープロセスを追跡する必要があります.我々はプロジェクトのスラックを使用します.

システム通知チャネルを作成し、すべてのCIとインフラストラクチャプロセスについて通知を送信できるようにします.

成功または失敗ステータスについての通知を設定し、ビルドが開始されたときに警告します.

イメージをシンプルに保つ

それはDocker画像env変数に渡すことはない最善の練習です.すべてのENV変数はDocker Runコマンドまたはあなたのオーケストレーションツールレベル(例えばKubernetes)を通過しなければなりません.これはまた、CIの設定ファイルをシンプルに保つのに役立ちます.

パイプラインの統一

今日の企業はマイクロサービスアーキテクチャをますます利用している統一されたパイプラインでは、これをより高速にスケーリングし、新しいマイクロサービスでCIを構成することによって利益を得ることができます.ドローンCIまたはTravis CIでは、あなたのパイプラインステップの間に使用可能なCI環境変数がたくさんあります.動作中のCI ENV変数の例をいくつか示します.

Dockerイメージをタグ付けするには、ビルド分岐とビルド番号の連結を使用できます.その結果、「マスター- 6」のようなものがありますまた、あなたのGitタグのバージョンを使用することができます.tags: "${DRONE_COMMIT_BRANCH}-${DRONE_BUILD_NUMBER}"

あなたのオーケストレーションツールの展開のリポジトリ名を使用します.ENV変数を持つKubernetesクラスタへのドローンCI展開の例

deploy:
   image: peloton/drone-k8s-deployment
   deployment_names: "${DRONE_REPO_NAME}"
   container_names: "${DRONE_REPO_NAME}"
   namespaces: microservices
   docker_image: "62673275295.dkr.ecr.eu-west-1.amazonaws.com/${DRONE_REPO_NAME}:${DRONE_COMMIT_BRANCH}-${DRONE_BUILD_NUMBER}"
   date_label: deployment.drone.io/date-deployed
   secrets: [kubernetes_url, kubernetes_token]

Travis CI ENV変数 Dockerイメージ名

あなたの環境の詳細と重要性に基づいて、Docker画像を命名するための戦略を定義する必要があります.たとえば、ロールバック機能を必要としない開発とUAT環境では、すべての新しいビルドが前の画像をオーバーライドするように、ブランチ名をタグとして使用できます.生産のために、それはリリース(v 1.0.0)のバージョン番号でイメージをタグ付けするほうがよいです.そして、それはあなたの登録をより多くの構造化して、そのサイズを減らすことによって読みやすくします.

ドローンCI ENV変数 使用ビルダーパターン

あなたがCIレベルで何かをコンパイルして、構築することができるならば、それは最終的なイメージにそれを置く前に余分なステップとしてこれをするのに役立つことができます.より良い理解を得るために見てください.

別々のステップとしてのDB移動

Dockerfileの一部として移行しないでください.代わりに、別のステップでそれを行う.資産または移行の編集のような余分のコマンドは別々のステップとして実行されなければなりません.また、あなたのDocker画像を取得し、可能な限りの時間の短い時間で実行してください.

プライベートライブラリとサブモジュールを避ける

プライベートNPMモジュールやサブモジュールのような余分な依存関係は、CI構成の設定プロセス中に問題を引き起こす可能性があります.たとえば、サブモジュールを持っていて、デフォルトでは、CIはHTTPと認証トークンを通してリポジトリへのアクセスしかありません.Gitを通したローカルマシンの設定は動作しません.サブモジュールをオーバーライドする必要があります.

あなたが個人的なNPMモジュールを使用する場合は、同様の問題に直面するでしょう.なぜなら、あなたは、Pockerイメージの中で、passkeysまたは既にダウンロードされたモジュールを必要とするでしょう.

概要

新しいプロジェクトのCIを設定するときは、ビルドの手順の成長と統合の名前の規則、可能性のある方法の定義と定義を考えてください.これは、より速く新しいサービスを展開するのを助けて、より速くパイプライン・プロセスの新しいプロジェクトと乗組員のための基礎工事としてそれらの実行を使用します.