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

https://www.digitalocean.com/community/tutorials/an-introduction-to-continuous-integration-delivery-and-deployment [継続的な統合、配信、および展開]は、CI / CDと総称されており、不可欠な部分です。プロジェクトの速度を向上させながら、統合および展開中のエラーを減らすことを目的とした最新の開発。 CI / CDは、多くの場合、ソフトウェアパイプラインの各段階での自動化されたテストを強調する堅牢なツールによって補強される哲学と一連の実践です。 これらのアイデアを実践に組み込むことで、リリースの変更を統合し、本番環境に移行する前に各変更を徹底的にテストするために必要な時間を短縮できます。

CI / CDには多くの潜在的な利点がありますが、実装を成功させるには多くの場合考慮が必要です。 ツールを使用する方法と、環境またはプロセスで必要な変更を正確に決定することは、大規模な試行錯誤なしで困難な場合があります。 ただし、実装はすべて異なりますが、ベストプラクティスを順守することで、一般的な問題を回避し、改善を迅速に達成することができます。

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

CI / CDパイプラインは、自動化されたテストサイクル、ステージング環境、最終的に本番環境への変更のシェパードを支援します。 テストパイプラインが包括的であればあるほど、変更が本番環境への予期しない副作用をもたらさないという保証が大きくなります。 ただし、各変更はこのプロセスを経る必要があるため、開発速度を阻害しないためには、パイプラインを高速かつ信頼できる状態に保つことが非常に重要です。

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

これらの重要な決定を下すとき、あなたが行っているトレードオフを理解し、文書化することを確認してください。 チームのメンバーや利害関係者と相談して、テストスイートの責任と主な重点分野についてチームの仮定を調整します。

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

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

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

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

ただし、これらの利点を実現するには、実稼働環境へのすべての変更がパイプラインを通過するように統制する必要があります。 CI / CDパイプラインは、コードが実稼働環境に入る唯一のメカニズムである必要があります。 これは、継続的な展開方法でのテストが正常に終了した場合、またはCI / CDシステムによって承認および利用可能になったテスト済みの変更を手動で昇格した場合に自動的に発生します。

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

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

特に後の段階では、本番環境をテスト環境で可能な限り厳密に再現することで、本番環境での変更の動作をテストが正確に反映できるようになります。 ステージングとプロダクションの重要な違いにより、テストで障害が発生することは決してなかった問題のある変更をリリースできます。 ライブ環境とテスト環境の違いが大きいほど、テストがリリースされたときにコードがどのように実行されるかを測定しなくなります。

ステージングと本番の間にいくつかの違いが予想されますが、それらを管理しやすくし、十分に理解されるようにすることが不可欠です。 一部の組織はhttps://www.digitalocean.com/community/tutorials/how-to-use-blue-green-deployments-to-release-software-safely[blue-green deployments]を使用して、ほぼ同一の2つのプロダクショントラフィックを交換します実稼働とステージングの指定を交互に行う環境。 それほど極端ではない戦略では、同じ構成とインフラストラクチャを運用環境からステージング環境に展開しましたが、規模は縮小されていました。 ネットワークエンドポイントなどの項目は環境によって異なる場合がありますが、このタイプの変数データのパラメーター化により、コードの一貫性と環境の違いを明確に定義できます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

一般的なCI / CDプラクティスおよびさまざまなCI / CDサービスの設定方法の詳細については、他のhttps://www.digitalocean.com/community/tags/ci-cd?type=tutorials[CI/の記事をご覧くださいCDタグ]。