序章

継続的インテグレーション、デリバリー、およびデプロイメントは、まとめてCI / CDと呼ばれ、プロジェクトの速度を上げながら、統合およびデプロイメント中のエラーを減らすことを目的とした最新の開発の不可欠な部分です。 CI / CDは、ソフトウェアパイプラインの各段階での自動テストを強調する堅牢なツールによって強化されることが多い哲学と一連のプラクティスです。 これらのアイデアを実践に取り入れることで、リリースの変更を統合するために必要な時間を短縮し、本番環境に移行する前に各変更を徹底的にテストできます。

CI / CDには多くの潜在的な利点がありますが、実装を成功させるには、多くの場合、十分な検討が必要です。 ツールの使用方法とプロセスで必要になる可能性のある変更を正確に決定することは、試行錯誤を繰り返すことなく困難な場合があります。 ただし、すべての実装は異なりますが、ベストプラクティスに従うことで、一般的な問題を回避し、より迅速に改善することができます。

このガイドでは、組織のニーズに最適なCI/CDシステムを実装および保守する方法に関する基本的なガイダンスを紹介します。 CI/CDサービスの有効性を向上させるのに役立ついくつかのプラクティスについて説明します。 書かれているとおりに読んでいただくか、興味のある分野に進んでください。

パイプラインを高速に保つ

CI / CDパイプラインは、自動化されたテストサイクルを通じて、ステージング環境に、そして最終的には本番環境に至るまで、変更を管理するのに役立ちます。 テストパイプラインが包括的であるほど、変更によって本番環境の展開に予期しない副作用が発生しないことを確信できます。 ただし、各変更はこのプロセスを経る必要があるため、パイプラインを高速で信頼できる状態に保つことは非常に重要です。

これら2つの要件の間の緊張は、バランスを取るのが難しい場合があります。 CI / CDインフラストラクチャのスケールアウトやテストの最適化など、速度を向上させるための簡単な手順がいくつかあります。 ただし、時間が経つにつれて、さまざまなテストの相対的な価値と、それらが実行される段階または順序について重要な決定を下さなければならない場合があります。 場合によっては、価値の低いテストや結論が不確定なテストを削除してテストスイートを削減することが、頻繁に使用されるパイプラインに必要な速度を維持するための最も賢い方法です。

これらの重要な決定を行うときは、行っているトレードオフを理解して文書化するようにしてください。 チームメンバーおよび利害関係者と相談して、テストスイートが何を担当し、主要な焦点領域が何であるかについてのチームの仮定を調整します。

CI/CD環境を分離して保護する

運用上のセキュリティの観点から、CI / CDシステムは、保護する必要のある最も重要なインフラストラクチャの一部です。 CI / CDシステムは、さまざまな環境に展開するためのコードベースとクレデンシャルに完全にアクセスできるため、セキュリティで保護することが不可欠です。 ターゲットとしての価値が高いため、CI/CDを可能な限り分離してロックダウンすることが重要です。

CI / CDシステムは、外部の関係者に公開されることなく、内部の保護されたネットワークに展開する必要があります。 認証されたオペレーターのみがシステムにアクセスできるようにするには、VPNまたはその他のネットワークアクセス制御テクノロジーをセットアップすることをお勧めします。 ネットワークトポロジの複雑さによっては、CI / CDシステムがいくつかの異なるネットワークにアクセスして、異なる環境にコードを展開する必要がある場合があります。 適切に保護または隔離されていない場合、1つの環境にアクセスする攻撃者は、アイランドホップを使用できる可能性があります。これは、より寛大な内部ネットワークルールを利用してアクセスを拡張し、 CI/CDサーバーの弱点。

必要な分離およびセキュリティ戦略は、ネットワークトポロジ、インフラストラクチャ、および管理と開発の要件に大きく依存します。 覚えておくべき重要な点は、CI / CDシステムは非常に価値のあるターゲットであり、多くの場合、他の重要なシステムに幅広くアクセスできることです。 サーバーへのすべての外部アクセスを保護し、許可される内部アクセスの種類を厳密に制御することで、CI/CDシステムが危険にさらされるリスクを減らすことができます。

CI/CDパイプラインを本番環境に展開する唯一の方法にする

CI / CDが開発プラクティスとコード品質を改善することを可能にするものの一部は、ツールがテストと展開のベストプラクティスを実施するのに役立つことが多いということです。 CI / CDパイプラインを介してコードをプロモートするには、組織の体系化された標準と手順に準拠していることを示すために、各変更が必要です。 CI / CDパイプラインの障害はすぐに表示され、影響を受けるリリースのサイクルの後の段階への進行を停止します。 これは、信頼できないコードからより重要な環境を保護するゲートキーピングメカニズムです。

ただし、これらの利点を実現するには、本番環境へのすべての変更がパイプラインを通過するようにする必要があります。 CI / CDパイプラインは、コードが実稼働環境に入る唯一のメカニズムである必要があります。 これは、継続的展開の実践によるテストの成功の最後に、またはCI / CDシステムによって承認され、利用可能になったテスト済みの変更の手動プロモーションを通じて自動的に発生する可能性があります。

多くの場合、チームは展開にパイプラインを使用し始めますが、問題が発生し、問題を迅速に解決する必要がある場合は、例外を作成し始めます。 ダウンタイムやその他の問題はできるだけ早く軽減する必要がありますが、CI / CDシステムは、変更によって他のバグが発生したり、システムがさらに破損したりしないようにするための優れたツールであることを理解することが重要です。 修正プログラムをパイプラインに通す（またはCI / CDシステムを使用してロールバックする）と、次の展開で、本番環境に直接適用されたアドホックホットフィックスが消去されるのを防ぐこともできます。 パイプラインは、これが定期的な計画されたリリースであるか、進行中の問題を解決するための迅速な修正であるかに関係なく、デプロイメントの有効性を保護します。 このCI/CDシステムの使用は、パイプラインを高速に保つために機能するもう1つの理由です。

可能な限り生産との同等性を維持する

CI / CDパイプラインは、一連のテストスイートと展開環境を通じて変更を促進します。 1つのステージの要件に合格した変更は、自動的にデプロイされるか、より制限の厳しい環境に手動でデプロイするためにキューに入れられます。 初期段階は、テストを継続し、変更を本番環境に近づけることが価値があることを証明することを目的としています。

特に後の段階では、テスト環境で本番環境を可能な限り忠実に再現することで、本番環境での変更の動作をテストに正確に反映させることができます。 ステージングと本番環境の大きな違いにより、テストでの欠陥が観察されなかった問題のある変更をリリースできる可能性があります。 ライブ環境とテスト環境の違いが大きいほど、リリース時にコードがどのように実行されるかをテストで測定することは少なくなります。

ステージングと本番環境にはいくつかの違いが予想されますが、それらを管理しやすくし、十分に理解されていることを確認することが不可欠です。 一部の組織では、青緑色の展開を使用して、本番環境とステージングの指定を交互に行う2つのほぼ同一の環境間で本番トラフィックを交換しています。 それほど極端ではない戦略では、同じ構成とインフラストラクチャを本番環境からステージング環境に展開しますが、規模は小さくなります。 ネットワークエンドポイントなどの項目は環境によって異なる場合がありますが、このタイプの変数データのパラメーター化は、コードの一貫性と環境の違いが明確に定義されていることを確認するのに役立ちます。

一度だけ構築し、パイプラインを通じて結果を促進する

CI / CDパイプラインの主な目標は、変更に対する信頼を構築し、予期しない影響の可能性を最小限に抑えることです。 環境間のパリティを維持することの重要性について説明しましたが、この1つのコンポーネントは、特別な注意を払うのに十分重要です。 ソフトウェアでビルド、パッケージ化、またはバンドルのステップが必要な場合は、そのステップを1回だけ実行し、結果の出力をパイプライン全体で再利用する必要があります。

このガイドラインは、ソフトウェアが複数回コンパイルまたはパッケージ化されたときに発生する問題を防ぐのに役立ち、結果として生じるアーティファクトにわずかな不整合が注入されることを可能にします。 新しい段階ごとにソフトウェアを個別に構築することは、以前の環境でのテストが、後で展開される同じソフトウェアを対象としておらず、結果を無効にすることを意味する可能性があります。

この問題を回避するには、CIシステムに、クリーンな環境でソフトウェアを作成およびパッケージ化するパイプラインの最初のステップとしてビルドプロセスを含める必要があります。 結果のアーティファクトは、バージョン管理してアーティファクトストレージシステムにアップロードし、パイプラインの後続のステージでプルダウンして、システムの進行中にビルドが変更されないようにする必要があります。

最速のテストを早期に実行する

パイプライン全体を高速に保つことは大きな一般的な目標ですが、テストスイートの一部は必然的に他の部分よりも高速になります。 CI / CDシステムは、システムに入るすべての変更の導管として機能するため、問題のあるビルドに費やされるリソースを最小限に抑えるために、障害をできるだけ早く発見することが重要です。 これを実現するには、最初に最速のテストに優先順位を付けて実行します。 小規模で高速実行のテストでビルドを検証するまで、複雑で実行時間の長いテストを保存します。

この戦略には、CI/CDプロセスを正常に保つのに役立つ多くの利点があります。 これにより、個々のテストのパフォーマンスへの影響を理解し、ほとんどのテストを早期に完了できるようになり、迅速な失敗の可能性が高まります。つまり、問題のある変更を元に戻したり、他のメンバーの作業をブロックする前に修正したりできます。

テストの優先順位付けとは、通常、プロジェクトの単体テストを最初に実行することを意味します。これは、単体テストが迅速で、分離され、コンポーネントに焦点を当てている傾向があるためです。 その後、統合テストは通常、次のレベルの複雑さと速度を表し、次にシステム全体のテスト、最後に受け入れテストが続きます。これには、ある程度の人間の相互作用が必要になることがよくあります。

バージョン管理システムでの分岐を最小限に抑える

CI / CDの主な原則の1つは、変更をプライマリ共有リポジトリに早期に頻繁に統合することです。 これにより、複数の開発者がリリースの準備のためにリポジトリのメインブランチに大規模で発散的で競合する変更をマージしようとするときに、コストのかかる統合の問題を回避できます。 通常、CI / CDシステムは、1つまたは少数のブランチにのみコミットされた変更を監視およびテストするように設定されています。

CIが提供する利点を活用するには、リポジトリ内のブランチの数と範囲を制限するのが最善です。 ほとんどの実装では、開発者がメインブランチに直接コミットするか、ローカルブランチからの変更を少なくとも1日1回マージすることを提案しています。

基本的に、CI / CDシステムによって追跡されていないブランチには、プロジェクトの成功と勢いに対する責任と見なされるべきテストされていないコードが含まれています。 分岐を最小限に抑えて、さまざまな開発者のコードの早期統合を促進することで、システムの長所を活用し、開発者がシステムの利点を無効にするのを防ぎます。

CI/CDパイプラインにコミットする前にローカルでテストを実行する

障害の早期発見に関する以前のポイントに関連して、開発者は、共有リポジトリにコミットする前に、ローカルでいくつかのテストを実行することを推奨する必要があります。 これにより、他のチームメンバーをブロックする前に、特定の問題のある変更を検出できます。 ローカルの開発者環境では、テストスイート全体を本番環境のような環境で実行できる可能性は低いですが、この追加の手順により、個人は、行っている変更が基本的なテストに合格し、より大きなコードベースと統合する価値があることを確信できます。

開発者が自分で効果的にテストできるようにするには、任意の環境から実行できる単一のコマンドでテストスイートを実行できる必要があります。 開発者がローカルマシンで使用するのと同じコマンドをCI/CDシステムで使用して、リポジトリにマージされたコードのテストを開始する必要があります。 多くの場合、これはシェルスクリプトまたはmakefileを提供することで調整され、繰り返し可能で予測可能な方法でテストツールの実行を自動化します。

可能な場合は、一時的な環境でテストを実行します

テストがさまざまな段階で同じように実行されるようにするために、可能であれば、クリーンで一時的なテスト環境を使用することをお勧めします。 通常、これは、コンテナーでテストを実行して、ホストシステム間の違いを抽象化し、さまざまなスケールでコンポーネントをフックするための標準APIを提供することを意味します。 コンテナーは最小限の状態で実行されるため、テストによる残りの副作用は、テストスイートの後続の実行によって継承されず、結果が損なわれる可能性があります。

コンテナ化されたテスト環境のもう1つの利点は、テストインフラストラクチャの移植性です。 コンテナーを使用すると、開発者は、インフラストラクチャを手動でセットアップして維持したり、環境の忠実度を犠牲にしたりすることなく、パイプラインの後半で使用される構成を簡単に複製できます。 コンテナーは必要なときに簡単にスピンアップして破棄できるため、ユーザーはローカルテストを実行する際のテスト環境の精度に関して妥協することが少なくなります。 一般に、ランタイム環境のいくつかの側面でコンテナーロックを使用して、パイプラインステージ間の違いを最小限に抑えます。

結論

CI / CDの実装はそれぞれ異なりますが、これらの基本原則のいくつかに従うことで、いくつかの一般的な落とし穴を回避し、テストと開発の実践を強化することができます。 継続的インテグレーションのほとんどの側面と同様に、プロセス、ツール、および習慣を組み合わせることで、開発の変更をより成功させ、影響力のあるものにすることができます。

一般的なCI/CDプラクティスと、さまざまなCI / CDサービスのセットアップ方法の詳細については、CI/CDタグが付いた他の記事を確認してください。