継続的インテグレーション(CI)とは?

「CI」という用語についてさらに文脈を提供するには、「CI」が継続的インテグレーションを意味する「Continuous Integration」の略であることを知っておくと良いでしょう。CI としてよく知られています。 CI は、定期的に同じプロジェクトで作業している全員がコードベースへの変更を中央のリポジトリにマージするようにするための手法というように定義されています。 プロジェクトでは通常 2 人以上の開発者が作業しているため、作業対象のコードを中央の 1 箇所にまとめることが重要です。 理想を言えば、このプロセスを自動化して 1 日に複数回実行すべきです。 継続的インテグレーションは、コラボレーション、自動化、および短いフィードバックサイクルを促進することで、信頼性の高いソフトウェアのビルド・リリース手法を維持することを目標としています。

継続的インテグレーションの実践は、定期的に変更をソース/バージョン管理システムにコミットし、全員が同じ基盤上でビルドできるようにすることから始まります。 コミットが行われるたびにビルドと一連の自動化テストが起動し、動作と変更による破損が生じていないことが確認されます。 継続的インテグレーションはそれ自体だけでも有益ではありますが、CI/CD パイプラインを実装するための第一歩でもあります。

明確な CI の定義を採用し、その手法を開発プロセスに実装することで、チームはワークフローを合理化し、ソフトウェアの品質を改善することができます。

継続的インテグレーション

CI の実践

継続的インテグレーションの重要な要素には、以下のものがあります。

  • ソースコードファイル、ライブラリ、構成ファイル、スクリプトなど、コードベース全体を含むソースまたはバージョン管理システム
  • 自動化されたビルドスクリプト
  • 自動化テスト
  • ビルドとテストを実行するためのインフラストラクチャ

全ての人が同一のコードを基礎にビルドするには、共通のリポジトリで作業し、変更を頻繁に共有し合うことが必要です。 原則として、1 日に最低 1 回は、マスター/トランクに各自の変更をコミットすることが推奨されます。

変更がコミットされれば、次に、ソリューションをビルドして一連の自動化テストを実施し、動作を確認する必要があります。 このプロセスの自動化は、継続的インテグレーションには不可欠です。ビルドやテストを手作業で行うと、時間が掛ってエラーが発生しやすくなり、変更を毎日統合するという目標は非現実的になってしまいます。 実際に使用するビルドツールとテストフレームワークは、作業に使用している言語によって異なります。

スクリプトとテストの準備ができたら、そのプロセスの管理が必要となります。 つまり、すべての新しい機能に自動テストを追加する、障害に対応する、およびプロセスのパフォーマンスを監視するという管理です。

リポジトリの監視、ビルドの起動、自動化テストの実行、結果の照合を実施できる CI サーバーを追加すると、これらの機能をまとめ、カスタム自動化ロジックの作成時間を減らし、コードカバレッジメトリクスやビルド履歴などの追加のインサイトを得られるようになります。

こういったツールとプロセスは継続的インテグレーションの実装に重要な要素ですが、継続的インテグレーションを最大限に活用するには、関係者にこの手法を受け入れてもらう必要があります。 開発チームでは、マスターへの定期的なコミット、すべての新機能への自動かテストの追加、なにかが正しく動作しなかった場合のビルドの修正作業の優先などが含まれるプロセスを採用する必要があります。 QA チームと協力して、自動化テストを優先、設計、および管理し、インフラストラクチャ担当者と協力して、ビルトとテストを実行するためのマシンをプロビジョニングすれば、組織内のサイロを取り壊すことができるでしょう。

継続的インテグレーションの課題

継続的インテグレーションには、開発者にだけでなく組織全体にもたらすメリットがありますが、必ずしも大歓迎されるというわけではありません。

多くの開発部門にとって DevOps は、作業方法が大きく変わることを意味しており、既存のプロセスを打ち消す存在として捉えられています。 そのため、チーム間の努力を調整し、コラボレーションのカルチャを植え付けるには、十分な話し合いが必要となります。

すでにアジャイル手法を実践しているのであれば、フィードバックに耳を傾けて正しいものをビルドすることの重要性と自己編成チームの概念に対する関心があると言えるため、DevOps への移行は少し簡単になるのが通例です。

そうでない場合は、これが重要な変化であることを認識して関係者に話しかけ、小規模なセットアップを出発点として実践を繰り返しながらメリットを示していくことで、同僚に関心を持たせることができます。

継続的インテグレーションは、より実際的な課題にも対応することができます。 大規模なモノリシックアプリケーションに取り組んでいる場合、ビルド時間が長引くだけでなく、テスト環境が不足していれば、テストランを並行化するのが困難になる可能性があります。

継続的インテグレーションワークフローを明確に理解し、メトリクスを使ってボトルネックを特定することで、アーキテクチャへの変更、追加インフラストラクチャ、およびテストカバレッジの自動化に投資するためのコストとメリットを定量化しやすくなります。

CI のメリット

継続的インテグレーションを利用すると、品質を損なうことなく、ソフトウェアのリリースサイクルを高速化できます。 継続的インテグレーションは、デプロイ中に発生する可能性のある潜在的なリスクを緩和し、フィードバックループを短縮することを主な目標としています。

継続的インテグレーションには主に以下のようなメリットがあります。

  • 低リスクのデプロイ。記述中のコードを継続的にマージすることで、発生するエラーを早い段階で解決できます。
  • 品質の向上。手動タスクの大部分を自動化することで、開発者をより高いレベルのテスト業務に専念させることができます。
  • コストの削減。継続的インテグレーションを導入すると、より小さな単位での出荷と大部分の作業の自動化が可能になるため、企業はソフトウェアのデリバリーに係るコストを大幅に削減できます。

CI/CD のベストプラクティス

継続的インテグレーション、デリバリー、デプロイは、企業がコストを削減し、ソフトウェアデリバリーサイクルを大幅に短縮するのに役立ちます。 これらは適切に実施すれば、ソフトウェアのビルド、テスト、リリースのプロセスを効率化する上で欠かせないものになります。 以下は、CI/CD ベストプラクティスの一部です。

  • コミットは早めに、頻繁に。より小さなアップデートをより頻繁に出荷することで、変更ごとにフィードバックを受信し、追跡することができます。 DevOps の現状レポートによると、パフォーマンスの高いチームのデプロイ回数は、パフォーマンスの低いチームの 417 倍であると推定されています。
  • ビルドを青信号に維持すること。新しいコードがコミットされるたびに自動テストを実行するように実装することで、CI/CD パイプラインからあらゆる変更に関するフィードバックを開発者へ迅速に提供できます。
  • 本番環境への唯一のデプロイ手段にすること。ソフトウェアを迅速にリリースする必要がある場合、十分に確立された CI/CD プロセスのステップを省略したくなることがあるかもしれませんが、 決められた方法をしっかり守ることで、コードベースに入り込む可能性のある問題を回避することができます。

CI/CD ツール

適切な CI/CD ツールを用いずに、安定した、信頼性のある CI/CD パイプラインを構築するのは不可能です。 このようなツールは、インテグレーションの開始から自動テストのトリガーや本番環境へのコードのデプロイまで、パイプラインのさまざまな部分を調整するのに役立ちます。 CI/CD プロセスのすべてのステージをサポートする TeamCity などの統合 CI/CD ツールを使用している場合でも、目的ごとに異なるツールに頼っている場合でも、チームが作業しているテックスタック全体をサポートするツールを選択する必要があります。 また、これらのツールが作業に使用するソフトウェアの他の部分と連携し、あらゆる複雑度のワークフローをサポートするのに十分なカスタマイズ性と柔軟性を備えていることも必要です。

CI と CD の比較

エラーのないソフトウェアをエンドユーザーに提供できるようにするには、CI と CD のメリットを比較するのではなく、開発プロセスのさまざまな部分が相互にどのように作用するのかを検討すると役立ちます。

継続的インテグレーションは、コードの変更を 1 つのメインブランチにマージするプロセスです。 継続的デリバリーは、継続インテグレーションステージで確立したテストとビルドの自動化を基礎にビルドを行います。 継続的デプロイは CI/CD プロセスの最終ステージです。ここでは、ソフトウェアの新しいバージョンがすべての要件を満たした場合に、エンドユーザーに提供されます。

CI と CD の比較について続きを読む

まとめ

継続的インテグレーションを採用することで、コードの品質を高めながら開発プロセスを科させることが可能になります。 これらのステップを自動化すれば、より効率的に作業を進められるようになり、ユーザーへの価値を高めることに専念できるようになります。 ただし、継続的インテグレーションは CI/CD パイプラインの始まりでしかありません。 この次のステージである継続的デリバリーは、DevOps の原則を CI プロセスの後のプロセスに適用している手法です。