DevOps における継続的インテグレーションの基礎

根本的に DevOps は、信頼性が高く安全な最終製品を確保しながら、ソフトウェア リリースの速度を向上させることを目指しており、継続的インテグレーションはこれを達成するために不可欠です。

継続的インテグレーションは、開発者がコードを共有リポジトリに定期的にマージすることを奨励する文化的プラクティスです。しかし、継続的インテグレーションは技術的プロセスでもあり、自動化とツール導入を組み合わせて使用することで、コード変更の統合、テスト、デプロイの準備を高速化します。

このガイドでは、以下について説明します。

• 継続的インテグレーションが必要な理由

• 継続的インテグレーションのベスト プラクティス

• 継続的インテグレーションのメリット

• 継続的インテグレーション パイプラインの仕組み

• 継続的インテグレーション パイプラインの構築を成功させる方法

継続的インテグレーションが必要な理由

継続的インテグレーションは、ソフトウェア開発における重要な問題 (複数のコントリビュータとの共有リポジトリにおけるコード インテグレーションの課題の管理) を解決することで、開発サイクルの高速化と効率化を促進しようとしています。

開発者は、ソフトウェアの更新やバグの修正に取り掛かるときに、作業用のコード ベースのコピーを作成します。これは、開発者がコード ベースのコピーを作成 (つまり「フォーク」) できる Git などのバージョン管理システムによって行われます。

より多くの開発者がコード ベースのコピーを作成するようになると、複数のコントリビュータからの変更を統合することが困難になります。特に、ある開発者が作業を開始したコード ベースが古くなり、メイン リポジトリと一致しなくなった場合は困難になります。

最悪のシナリオでは、一致していないコードをそれぞれの開発者が解消しようとするため、コード変更をうまく統合するのに、各自で変更するよりも時間がかかる可能性があります。開発者はよくこれを「インテグレーション地獄」と呼びます。

継続的インテグレーションは、開発者が変更を加えるたびにインテグレーションするよう促すことで、これを防止しようとしています。また、継続的インテグレーションは自動化を活用してコードの統合とテストを高速化し、追加の変更が必要ないことを確認し、開発者の負担を軽減します。より頻繁なコード インテグレーションに自動ビルドとテストを組み合わせることで、ソフトウェア開発プロセスのスピードアップに役立ちます。

継続的インテグレーションを導入する際のベスト プラクティス

各企業は、独自のニーズに応じて継続的インテグレーション プラクティスを定義します。企業によっては、より厳格な自動セキュリティ テストを導入する場合があります。他の企業は、迅速なコードのマージを優先し、より時間のかかる自動テストをソフトウェア開発ライフサイクル (SDLC) の後半に予約する場合もあります。

それにもかかわらず、効果的な CI パイプラインは、一連の共通ツールとベスト プラクティスを共有しています。これには以下が含まれます。

共有コード リポジトリ

バージョン管理システムの共有コード リポジトリは、効果的な継続的インテグレーション プラクティスを作成するための基礎となります。バージョン管理システムは、コード、スクリプト、自動テストなどを保存する場所として機能するだけでなく、開発者が作業の拠点となる複数のブランチを作成することもできます。

定期的なコード コミット

自動化、テスト、ツールは、効果的なパイプラインを構築するために重要ですが、頻繁なコード変更のコミットを優先するチーム文化の転換がなければ、大きな成果を上げることはできません。開発者がコードをコミットする頻度について厳密なルールはありません。ただし経験則として、個人が変更をコミットする頻度が高いほど、開発環境の生産性は高くなります。

ビルドの自動化

ビルドの自動化は CI パイプラインの重要なコンポーネントであり、チームがソフトウェア ビルドを標準化できるようになります。典型的なビルド プロセスには、ソース コードのコンパイル、ソフトウェア インストーラの生成、デプロイを成功させるために必要なアイテムが全て揃っていることの確認が含まれます。継続的インテグレーション プラクティスでは、このプロセスは自動化され、段階的なコード コミットをコード ベースに統合するのに役立ちます。

自動テスト

大量のコード コミットを行い、完全に自動化されたビルド プロセスを実行できます。しかし、プログラムが実行されたからといって、正しく実行されているとは限りません。そこでテストの出番です。自動テストは CI パイプラインの重要な部分です。コミットごとに、バグ、セキュリティ上の欠陥、コミットの問題を特定するための一連のテストをトリガーします。これらのテストは、メイン コード ブランチを稼働状態、つまり「グリーン」に保ち、コード変更の有効性について開発者に迅速なフィードバックを提供することを目的としています。

継続的インテグレーションのメリット

継続的インテグレーションが最も効果的な場合、組織はソフトウェアをより迅速に構築し、より信頼性の高いソフトウェアをリリースし、ビジネス全体の健全性を向上させることができます。

しかし、これらは組織全体の大まかなメリットです。実際には、継続的インテグレーションを導入することで、いくつかの実質的なメリットが期待できます。これには以下が含まれます。

コード変更の高速化

継続的インテグレーションでは頻繁なコード コミットが優先されるため、組織は開発チームの作業速度の向上を実感できます。各開発者は、他のチーム メンバーと協力しながら、特定のソフトウェアのより小さな部分に取り組んでいます。また、継続的インテグレーションは大規模なコード更新ではなく、定期的な小さなコード変更を要求するため、統合、テスト、そして最終的にはエンド ユーザーへのコードのリリースがよりシンプルになります。

テストの信頼性の向上

継続的インテグレーションの導入に成功した組織は、一般的にテストの信頼性が向上したと報告しています。これは、テストがソフトウェア開発ライフサイクルの継続的かつ日常的な一部になるためです。テストが失敗した場合は、ソフトウェアに欠陥があるか、テスト自体を書き直す必要があることを示します。より信頼性の高いテストを行うことで、CI パイプラインは開発、コード インテグレーション、ソフトウェア リリースをより迅速に行うことができます。

障害分離

障害分離は、開発者が潜在的な問題の範囲と損害を最小限に抑えるシステムを構築するための技術概念です。CI パイプラインでの障害分離の使用は一般的な方法であり、メリットでもあります。開発者は多くの場合、自動テストと障害分離やシステム監視を組み合わせることで、ビルド ステージでの大規模なソフトウェア障害を防止し、各問題の修正を容易にします。

平均修復時間 (MTTR) の改善

平均修復時間は、コーディング エラーの修正にかかる時間の測定値です。適切な DevOps 手順を実践しているチームは、平均修復時間を使用することで、稼働時間を維持し、システム障害につながる問題を解決することにどの程度成功しているかを測定できます。継続的インテグレーション プラクティスでは小規模で段階的なコード変更が優先されるため、CI パイプラインを導入する企業は、平均修復時間測定の改善と稼働時間のパフォーマンスの向上を実感できます (通常は自動デプロイと組み合わせて)。

迅速なソフトウェア リリース

改善されたテスト、平均修復時間、潜在的なエラーの範囲を制限する障害分離の使用により、CI パイプラインは通常、ソフトウェア リリースの速度が速くなります。ただし、これを真に保証するには、組織は、より頻繁なコード コミット率を促すことで文化的に、またテストを自動して完全な CI パイプラインを作成することで技術的に、継続的インテグレーションを適切に実装する必要があります。その一環として、顧客が個々のソフトウェア リリースのテストに使用するのと同じ本番環境を作成します。

重大でないバグのバックログの削減

CI パイプラインは、ソフトウェア リリースの前に自動テストによってバグを特定することで、本番環境で発生する重大でないバグの数を削減できます。そうすることで、開発者はこれらのバグを修正するだけでなく、将来のバグのバックログや技術的負債を削減することもできます。これにより開発者は、バックログの問題ではなく、より大規模な機能アップデートに集中できるようになります。

チーム コミュニケーションの向上

最適な CI パイプラインは、継続的なテスト、監視、レポートを活用して継続的なフィードバックのストリームを生成し、これを使用してソフトウェアの安定性を向上させます。継続的なフィードバックは、チーム コミュニケーションの向上と、問題が発生したときに解決するための責任範囲の改善にも役立ちます。

組織コストの削減

CI パイプラインは自動化に大きく依存しているため、一般的に組織コストが削減されます。DevOps サークルでよく言われるのは、自動化できるものは全て自動化する必要があるということです。文化的かつ技術的なプラクティスとして、CI パイプラインの自動化はヒューマン エラーのリスクを軽減します。また、既存のコードのテストではなく、コードの構築に取り組む組織のリソースを解放します。

継続的インテグレーション パイプラインのしくみ

CI パイプラインは、ソフトウェア開発ライフサイクル (SDLC) の最初の 3 つのステージ、つまりビルド、テスト、リリースに焦点を当てています。これらの最初の 3 つのステージに自動化と監視を導入することで、継続的インテグレーションは SDLC を高速化し、組織がより信頼性の高いソフトウェアをデプロイできるように支援します。

もちろん、手動でソフトウェアをビルド、テスト、リリースすることも可能です。ただし、継続的インテグレーションの本当のメリットは、これらの各ステップに自動化を適用することです。

CI パイプラインのステージ

1. ビルド

これは、アプリケーションがコンパイルされるステージです。CI パイプラインでは、開発者がコード変更をメイン リポジトリにコミットすると、自動化を使用してビルド サイクルがトリガーされます。ここから、CI ツールはプロジェクトのビルド ツールをクエリし、クリーンなステージング環境でアプリケーションのコンパイルを開始します。コンテナは一般的で軽量な方法であり、組織がこのステージで新しいビルド環境を立ち上げる際によく使用されます。

2. テスト

アプリケーションがコンパイルされた後、コードが動作し、バグや重大な問題がないことを確認するために一連のテストが実行されます。組織は、アプリケーションのコンパイル後にこれらのテストが自動的に開始されるように CI ツールを設定します。ユニット テスト (コードの小さな単位をテストする方法) は、記述が簡単で、実行と維持にかかるコストが低いため、このステージではよく使用されるテストです。このステージでの CI パイプラインの目標は、コード ベースがインスペクションに合格することを確認することです。

3. パッケージ

次に、組織はコードのパッケージ化を開始します。CI パイプラインでは、これらのステップは自動化されており、ユニット テストが完了するとトリガーされます。各組織がコードをパッケージ化する方法は、プログラミング言語と本番環境によって異なります。たとえば、JavaScript と Docker コンテナを使用している組織は、npm と Docker イメージを使用してコードをパッケージ化する場合があります。

成功する継続的インテグレーション パイプラインの構築を開始する方法

まず、まったく同じ CI モデルは 2 つとしてありません。どの組織も、独自のニーズとチームの要件に従って継続的インテグレーションを実装します。

しかし、継続的インテグレーションを正常に実装するには、全ての組織が実行する必要がある共通のステップがいくつかあります。これらは 7 つのプラクティスに分類されます。

1. テスト戦略を策定する

全ての継続的インテグレーション プラクティスは、説得力のある明確なテスト戦略から始まります。どのような種類のテストを実行するのか、自動テスト シーケンスの構築にどのようなトリガーを使用するのか、開発チームが作業する各コーディング ブランチにどのテストを適用するのかを検討する必要があります。

参考までに、CI パイプラインでよく使用されるテストには次の 3 種類があります。

• ユニット テストは、コード内で個々の関数が動作するかどうかを検証する単純なテストです。

• インテグレーション テストは、コード変更がより大きなコード ベースと正確に統合されていることを確認します。

• 受け入れテストは、アプリケーションが機能要件を満たしているかどうかを検証します。これらのテストの一部は、厳密には UI テストと呼ばれ、ユーザーが遭遇すると予想される UI 機能を検証します。

3 種類の全てのテストから始める必要はありません。ほとんどの組織では、ユニット テストと統合テストから始めて、受入テストの作成に進みます。

2. CI ツールを選択する

CI プラットフォームの選択は、どのような組織でも CI モデルを構築する上で重要な部分です。これは、自動化されたビルド、テスト、パッケージ、リリースをトリガーするツールです。

CI プラットフォームを選択する際には、いくつかの質問をする必要があります。これには以下が含まれます。

• 現在のテクノロジー スタックとどの程度うまく統合されていますか? プログラミング言語から、バージョン管理システム、サードパーティ ツールに至るまで、CI プラットフォームはスタック内の全てと簡単に統合できる必要があります。また、将来導入する可能性のある技術を考慮し、拡張可能なプラットフォームを探すことも価値があります。

• コンテナをネイティブにサポートしていますか? コンテナは DevOps と継続的インテグレーション プラクティスの重要な部分であり、CI プラットフォームが Docker などのコンテナ アプリケーションをネイティブにサポートしていることを確認することが重要です。現在はコンテナを活用しないかもしれませんが、DevOps プラクティスが拡大するにつれて、何らかの形でコンテナを使用するようになる可能性は十分にあります。

• マトリックス ビルドのテスト機能が有効になっていますか? マトリックス ビルドを使用すると、複数のオペレーティング システムやランタイム バージョンにまたがるビルドを同時にテストできます。マトリックス ビルドをネイティブにサポートしている CI ツールを探してください。マトリックス ビルドは、テストを効率化し、アプリケーションが全てのエンド ユーザーで動作することを保証します。

• 組み込みのコード カバレッジとテストの視覚化を提供しますか? コード カバレッジとテストの視覚化により、現在テストされているコード ベースの量、現在のテストがリアルタイムで実行されている様子、過去のテストが実行された様子を簡単に確認できます。

• セキュリティ要件にどのように対応しますか? セキュリティは、どのような技術投資においても重要な考慮事項です。特に、その投資がコード ベースやコア サービスと深く統合される場合は重要です。

3. できるだけ早くコードを統合する

CI の導入を成功させるには、開発者ができるだけ早くコードを共有リポジトリに統合することから始まります。

これには 2 つのメリットがあります。

1. 古いブランチをメイン リポジトリにマージし直すときに発生する可能性のある、大規模なインテグレーションの衝突を回避できます。

2. 小さなコード変更を定期的に統合することになるため、チーム間の知識の伝達に役立ち、テスト計画が簡素化されきます。

また、既存のソフトウェア開発ライフ サイクルが現在どのようになっているか、CI パイプラインを実装する際に、今後手続き上どのような変更を加える必要があるかを考慮する必要があります。これは、機能ブランチとトランクベースの開発のどちらが優れているかという話ではありません。代わりに、コーディング、テスト、マージ、レビューの安定した流れを促進する組織的な開発ワークフローがあることを確認してください。

4. メイン ブランチが壊れたらすぐに修正する

確かな経験則から、メイン ブランチが壊れたらすぐに修正する必要があります。

CI モデルでは、開発者はコード変更をできるだけ早く統合する必要があります。これはよいことです。しかし、コード変更によってメイン ブランチが壊れ、開発者がさらに変更を追加し続けた場合、最初の失敗の原因を特定することが困難になります。

そのため、1 つのコード変更によってメイン ブランチが壊れたときに、開発者に直ちに通知するテストを作成します。これは、DevOps の重要なプラクティスであるフィードバック ループの作成に役立ちます。

ビルドをグリーンに保つ、つまり稼働状態を保つためには、テストの速度とテスト カバレッジのバランスを取るようにしてください。テストの実行に時間がかかりすぎると、どのコード変更が失敗の原因になったかを特定するのが難しくなります。最適なテスト スイートは、ビルド テストやインテグレーション テストなどの簡単なテストから開始して、より時間のかかるテストに進みます。

5. 新しい機能を導入するたびに新しいテストを作成する

CI モデルでは、テスト スイートはソフトウェアやアプリケーションに応じて拡張する必要があります。つまり、新しい機能を構築し、大規模なアップデートを準備する際には、これらの機能を検証するためのテストも作成する必要があります。

新しい機能を構築したりバグを修正したりする際には、テストを作成することを検討してください。これには時間がかかるように感じるかもしれませんが、後からテストを作成する方が、コードを構築しながらテストを作成するよりも確実に時間がかかります。