CI サーバーについて

At the start of any CI/CD pipeline is an integration with your version or source control system.

基本的には、CI/CD サーバーがマスターブランチのコミットをリッスンし、変更が行われるとパイプラインをトリガーするように構成します。

これによって各コミットの確認とテストが行われるようになりますが、それだけでは、個々のユーザーがビルドを破損させ、プロセスを中断し、問題のあるコードが取り除かれるか修正されるまで他の変更が確認できないようなコミットをしてしまう可能性が残っています。

CI サーバーを、変更がコミットされる前にビルドしてテストするように構成すれば、こういった問題を未然に防ぎ、各開発者が使用できる追加のフィードバックループを作成することができます。

重要なのは、ビルドサーバーが、ビルドとテストをリモートマシンで実行し、結果を各開発者に戻すというイネーブラーの役割だけでなく、マスターや機能ブランチへのコミットの条件を処理するというエンフォーサーの役割も果たしているということです。

検討をお勧めするもう 1 つのステップは、CI サーバーをコードレビューツールに統合することです。各コミットは、正常にビルドおよびテストされた後でのみ、コミット前にコードレビューに合格する必要があるようにすることができます。

こういったビジネスロジックの追加レイヤーをプロセスの始めに適用しておくことで、コードベースをクリーンに維持し、リリースできる状態を保ちやすくなる一方、パイプラインの中断や遅延を最小限に抑えられるようになります。

CI/CD のビルドとテストのフェーズに関しては、CI サーバーがオペレーションの頭脳としての役割を果たし、さまざまな基準に基づいてタスクを調整しながら、ビルドエージェントにジョブを割り当てます。

ただし、最も手間のかかる部分を行うのはビルドエージェントで、CI サーバーから受け取った指示に従って、ビルドを起動してテストを実行します。

少なくとも本番のセットアップにおいては、リソースの競合やパフォーマンスの問題を回避するために、ビルドサーバーを、ビルドを起動してテストを実行するビルドエージェントから切り離しておくことが推奨されます。

CI サーバーを使用してパイプラインのステージのロジックを構成する際、広範な詳細とルールを指定することができます。 たとえば、マスターブランチへのコミットに対しては特定のテストを実行しても、開発ブランチにあるコミット前のビルドを実行する場合はテストを実行しないようにしたり、当時にテストデータベースを呼び出せるビルドの数を制御したりすることができます。

異なるビルドエージェントを使用して特定のタスクを同時に実行して、パイプラインの効率性を高めることができます。 これは、異なるオペレーティングシステムでテストを実行する必要がある場合や、テストが数十万個に及ぶ大規模なコードベースを取り扱っており、唯一の実用的なオプションが並行化である場合に便利です。 In the latter case, setting up a composite build will aggregate the results so you can treat the tasks as a single build step.

AWS などのクラウドでホスティングされているインフラストラクチャと統合されたビルドサーバーの場合、ビルドとテストを実行するための弾力性のあるスケーラブルなリソースのメリットが得られます。 インフラストラクチャのニーズが大きい場合は、コンテナー化されたビルドエージェントと Kubernetes との統合のサポートを利用して、クラウドかオンプレミスかに関係なくビルドリソースを効率的に管理することができます。

ビジネスロジックには、CI/CD パイプラインの各ステージにおける「失敗」を定義する重要な役割があります。

Your CI server should allow you to configure various failure conditions, which it will then apply and use to determine the status of a particular step and whether to proceed to the next stage of the pipeline.

エラーコードを返しているビルドやテストの実行に失敗しているテストなどといった自明の失敗に加えて、ビルドサーバーによって収集されたデータに基づいて他の種類の失敗を定義できます。

以前のビルドと比較してテストカバレッジが減少している場合（テストが最新のコード変更ように追加されていないことを示す）や、最後の成功ビルドと比較して無視されたテストの数が増加している場合、などの例が挙げられます。

これらのメトリクスは、コードの品質が劣化していることを示す警告として役立ちます。 こういった理由によって失敗をトリガーし、これらの失敗をオーバーライドする権限を持つユーザーを制限することで、望ましい行動を促進することができます。

「CI サーバー」という名称から、その使用は継続的インテグレーションに限られているように思えますが、ほとんどの CI サーバーは継続的デリバリーとデプロイもサポートしています。

継続的インテグレーションフェーズにおいてビルドアーティファクトを生成し、最初のテストセットを実行したら、次のステップは、それらのアーティファクトを QA 環境にデプロイしてさらに詳細なテストを実施することです。その後、関係者が試用できるようにステージングに移行し、それがうまく行けば、本番にリリースすることができます。

As well as providing an artifact repository to store the outputs from each build so you can deploy them as needed, a CI/CD server can also store and manage parameters for each environment in your pipeline. 後は、前のステージの結果に基づいてデプロイスクリプトを自動的にトリガーするかどうかを指定するだけです。

CI/CD パイプラインでは、各ステージのフィードバックを迅速に適用できることが重要な要素です。

ビルドサーバーはキューに入っているジョブ、進行中のビルドとテストのリアルタイムレポート、さらに完了したビルドステップのステータスに関する情報を提供することができます。

通知を有効にしておけば、問題が発生した時点で課題を存在をあなたやチームに知らせることができます。またバグトラッキングツールとの統合によって、コミットに含まれていた修正の詳細を確認できるため、失敗の原因を素早く突き止めることができます。 履歴データからは、パイプラインを改善するためだけでなく、パイプラインロジックの一環として条件を定義するための有益なインサイトを得ることができます。

継続的インテグレーション (CI) サーバーは、CI/CD パイプラインを実装し、プロセスのさまざまなステップを調整・トリガーし、各ステージから得られるデータを照合・提供する上で、欠くことのできない役割を果たしています。 Have a look at our Guide to CI/CD tools for tips on how to choose the right CI server for your organization.