クラウドベースの継続的インテグレーション (CI)/継続的デリバリー (CD) プラットフォームの選択方法

[[406218]]

[51CTO.com クイック翻訳]継続的インテグレーション (CI)/継続的デリバリー (CD) をクラウド プラットフォームでホストすると、開発パイプラインとソース コード リポジトリ間のやり取りが高速化されるだけでなく、開発者の作業も容易になります。

組織の目標がソフトウェア開発プロセスを高速化すること、または実用的なビルドを本番環境に頻繁に提供することである場合、テストと配信のプロセスを自動化する必要があります。理想的には、これは組織がプロジェクト用の継続的インテグレーション (CI)/継続的デリバリー (CD) パイプライン、顧客がソフトウェアを使用する前にバグを検出するテスト スイート、およびビルド パイプラインの手順を実装するスクリプトを構築することを意味します。

継続的インテグレーション (CI) は、ソフトウェアの構築、パッケージ化、テストを一貫した方法で自動化する方法です。継続的インテグレーション (CI) は、開発チームがソース コード バージョン管理にチェックインする変更によってビルドが中断されたり、ソフトウェアにバグが導入されたりしないことを判定するのに役立ちます。継続的インテグレーション (CI) のエンドポイントは通常、ソフトウェア リポジトリのマスター ブランチへの完全なチェックインです。

継続的デリバリー (CD) は、テスト済みのソフトウェアをインフラストラクチャ環境に自動的に配信しますが、これを直接本番環境に導入することを意味するものではありません。通常、組織はまず構築したソフトウェアを開発環境にプッシュします。開発者が新しいバージョンに取り組んでリリースした後、そのバージョンは通常、テスト環境に移行され、より広範なユーザーベース (専用の社内テスターのみの場合もあれば、ベータ版にサインアップしたユーザーの場合もあります) によって使用され、厳密に監視されます。最後に、すべてがうまくいけば、テスターはソフトウェアの新しいバージョンを確認して運用環境にプッシュします。

CD プロセスの各段階で、古いバージョンにすばやく戻したり、開発者が新しいバージョンでバグを修正できるようにバグ レポートを生成したりするためのオプションがあります。目標は、大量のビルドを本番環境に導入することではなく、回帰を導入することなくソフトウェアを継続的に改善および強化することです。これらのプラクティスの別名は「DevOps」です。

CI/CD をクラウドでホストする理由は何ですか?

継続的インテグレーション (CI)/継続的デリバリー (CD) プラットフォームを独自のデータ センターでホストすることは、特にアプリケーションとデータをファイアウォール内でホストする必要がある組織にとって実行可能なオプションです。この方法の欠点は、組織がインフラストラクチャを維持するための専任チームを必要とし、サーバーを購入して運用するための資本支出が発生することです。

クラウドでのホスティングが許可されている場合は、通常これがより良い選択肢となります。クラウド プラットフォーム ホスティングのコストは中程度であり、その運用費用は、オンボーディング、インフラストラクチャ メンテナンス、セキュリティ メンテナンス、サポート、継続的インテグレーション (CI)/継続的デリバリー (CD) ソフトウェア メンテナンスなどの提供されるサービスによって相殺されます。 CI/CD ソフトウェアをクラウドでホストすると、パイプラインがソース コード リポジトリとやり取りするのがより簡単かつ迅速になります。組織の開発者とテスターが地理的に分散している場合、リポジトリをファイアウォールの背後にあるリモート サーバーでホストするよりも、クラウドでホストする方が開発者のエクスペリエンスが向上することがよくあります。

組織は、オンプレミスとクラウド プラットフォームにわたるハイブリッド展開シナリオで継続的インテグレーション (CI)/継続的デリバリー (CD) を実装することもできます。最新の継続的インテグレーション (CI)/継続的デリバリー (CD) 製品の一部は、オンプレミスでもクラウドでも同様に実行される Kubernetes クラスターのコンテナーで実行されます。ハイブリッド展開シナリオでは、組織は開発者自身の物理的な場所と開発インフラストラクチャ内の他のサーバーのネットワーク上の場所を考慮して、各コンポーネントを最も適切な場所に配置できます。

継続的インテグレーション（CI）/継続的デリバリー（CD）は組織のリポジトリと統合する必要がある

リポジトリは継続的インテグレーション (CI)/継続的デリバリー (CD) に不可欠です。ソフトウェア リポジトリは、チェックインとテスト プロセスのエンドポイントであるだけでなく、継続的インテグレーション (CI)/継続的デリバリー (CD) のスクリプトと構成ファイルを保存する場所としても適しています。多くの継続的インテグレーション (CI)/継続的デリバリー (CD) プラットフォームでは、スクリプトやその他のファイルを内部に保存できますが、ツール外部のバージョン管理に配置するのが最適です。

ほぼすべての継続的インテグレーション (CI)/継続的デリバリー (CD) ツールは Git と対話できます。一部は GitHub、GitHub Enterprise、GitLab、Bitbucket と直接統合され、Subversion や Mercurial もサポートしています。

組織のCI/CDツールはプログラミング言語とツールをサポートする必要があります

各プログラミング言語または言語グループ (JVM 言語、LLVM コンパイル言語、.NET 言語など) には、独自のビルド ツールとテスト ツールがある傾向があります。したがって、継続的インテグレーション (CI)/継続的デリバリー (CD) ツールは、特定のプロジェクトに含まれるすべての言語をサポートする必要があります。それ以外の場合、組織はツール用のプラグインを 1 つ以上作成する必要がある場合があります。

Docker イメージは、分散型、モジュール型、マイクロサービス型のソフトウェアのデプロイメントにとってますます重要になっています。継続的インテグレーション (CI)/継続的デリバリー (CD) ツールが、ソース コード、バイナリ、前提条件からイメージを作成し、特定の環境にイメージをデプロイするなど、Docker イメージの操作方法を認識していれば、非常に役立ちます。この機能がなければ、組織は必要な Docker 機能を実装するためにプラグインまたはスクリプトを作成する必要がある場合があります。組織は、Kubernetes や環境内で使用されるその他のコンテナ オーケストレーション システムをサポートする継続的インテグレーション (CI)/継続的デリバリー (CD) ツールを必要としています。

開発者は CI/CD と組織が検討しているツールを理解していますか?

継続的インテグレーション (CI) / 継続的デリバリー (CD) の原則は明白に思えるかもしれませんが、詳細はそうではありません。さまざまな継続的インテグレーション (CI)/継続的デリバリー (CD) ツールには、さまざまなレベルのサポートとドキュメントがあります。その他の製品については、ツールを選択する際のデューデリジェンスの一環として、ドキュメントやサポート フォーラム、有料サポート オプションを調査する必要がある場合があります。

組織は、1 つのプラットフォームがすべてのソフトウェア開発プロジェクトに最適であると想定してはなりません。ほとんどの組織では複数のプログラミング言語と環境を使用していますが、それらはすべての継続的インテグレーション (CI)/継続的デリバリー (CD) プラットフォームで十分にサポートされているわけではありません。

組織は、妥協したプラットフォームを探すのではなく、各プロジェクトに最適な CI/CD プラットフォームを選択する必要があります。継続的インテグレーション (CI)/継続的デリバリー (CD) の原則は、組織がそれらのために作成したスクリプトが必ずしも移植可能ではない場合でも、あるプラットフォームから別のプラットフォームに転送可能です。 DevOps チームが新しいプラットフォームを学習して慣れるにはある程度の時間がかかるかもしれませんが、CI/CD ツールを大幅にカスタマイズするよりもコストは低くなる可能性が高くなります。

将来の CI/CD 移行の計画

同様に、組織は、特定の継続的インテグレーション (CI)/継続的デリバリー (CD) プラットフォームが常にプロジェクトのニーズを満たすと想定すべきではありません。たとえば、継続的インテグレーション (CI)/継続的デリバリー (CD) ツールではなく、リポジトリにスクリプトを保存します。

適切な場合はサーバーレス CI/CD を優先する

一般的に、コンテナのデプロイメントはクラウド コンピューティング サーバー インスタンスのデプロイメントよりも安価であり、サーバーレス クラウドのデプロイメントはコンテナのデプロイメントよりも安価です。現在、サーバーレスで実行できる継続的インテグレーション (CI)/継続的デリバリー (CD) プラットフォームはほとんどありません。

サーバーレスとは​​、対象のプロセスを実行するコンテナが、通常はイベントに応じて必要なときにインスタンス化されることを意味します。 CI/CD の場合、トリガー イベントは通常、特定のリポジトリ ブランチへのコード チェックインです。その後、リポジトリ Webhook がサーバーレス プロセスを開始します。プロセスが完了すると、これらのリソースは解放されます。

サーバーレスで実行できる数少ない継続的インテグレーション (CI)/継続的デリバリー (CD) プラットフォームの 1 つが、Serverless Framework の拡張バージョンである Serverless CI/CD です。サーバーレス CI/CD はサーバーレス アプリケーションのデプロイ用に最適化されており、現在は AWS クラウド プラットフォーム上でのみ実行されます。組織は、使用時にそれが自社のアプリケーションを適切にサポートするかどうかを判断する必要があります。

現在のクラウド コンピューティング資産はどこにありますか?

クラウドベースの CI/CD 構成を最適化するには、すべてのアセットが互いに「近い」ことが役立ちます。 「近い」という用語は、地理的な場所が互いに近いこと、またはネットワークの場所が互いに近いことを指します。

たとえば、組織のデータベースがオーストラリアに保存され、アプリケーションが北米にある場合、アプリケーションがデータを読み書きする必要があるたびに、大きな遅延が発生する可能性があります。小規模な場合、アプリケーションとデータベースが同じクラウド アベイラビリティ ゾーン (AZ) にあると、それらの間のレイテンシは最小限に抑えられます。同じリージョン内の異なるアベイラビリティーゾーン (AZ) にある場合、レイテンシーは増加しますが、異なるリージョンの場合ほど高くはなりません。

同様に、データベースがバージニア州の Google Cloud Platform 上にあり、アプリケーションがバージニア州の Microsoft Azure Cloud Platform 上にある場合、データベースとアプリケーションが同じアベイラビリティーゾーン内の同じクラウド プラットフォーム上にある場合よりもレイテンシが高くなります。これらはすべて、組織のリポジトリ、CI/CD ソフトウェア、実際のアプリケーション、開発者やテスターに​​も当てはまります。これらすべてが互いに「近い」と役立ちますが、この場合の遅延の影響は、リアルタイムのインタラクティブ ゲームの場合ほど顕著ではありません。

開発者は、目立った遅延なく、確実にコードコミットをメインリポジトリにプッシュできれば、一般的に良いエクスペリエンスを得ることができます。同様に、ユーザーやテスターがアプリケーションに「アプローチ」して 1 秒未満の応答時間を得る場合も同様です。継続的インテグレーション (CI)/継続的デリバリー (CD) ソフトウェアの場合、デプロイメント ポイントへの信頼性の高い接続が重要です。タイムアウトやパケット損失が発生しない限り、多少の遅延は許容されます。

継続的インテグレーション (CI)/継続的デリバリー (CD) が完全に実装されると、それはインフラストラクチャの重要な部分になります。これは、組織が実装を加速する際に留意すべき点です。

CI/CD パイプラインの展開を開始する前に、厳密な概念実証を実行することが重要です。継続的デリバリー (CD) フェーズを開始する前に、まず継続的インテグレーション (CI) の部分を処理する必要があります。 CI/CD パイプラインを本番インスタンスに接続する前に、テスト スイートとロールバック機能を練習し、自動化が信頼できると確信できるまで従業員を関与させるようにしてください。

原題: クラウドベースの CI/CD プラットフォームの選び方、著者: Martin Heller

[51CTOによる翻訳。パートナーサイトに転載する場合は、元の翻訳者と出典を51CTO.comとして明記してください。