クラウドベースの CI/CD プラットフォームを選択するにはどうすればよいでしょうか?

[[413408]]

この記事はWeChat公式アカウント「新チタンクラウドサービス」から転載したもので、黄浩傑が翻訳しました。この記事を転載する場合は、Xintai Cloud Service公式アカウントまでご連絡ください。

クラウドで 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 のエンドポイントは通常、ソフトウェア リポジトリのマスター ブランチへの完全なチェックインです」という説明を読んでお分かりのように、リポジトリは 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 機能を実装するためにプラグインやスクリプトを作成する必要がある場合があります。同様に、CI/CD ツールでは、Kubernetes や環境内で使用するその他のコンテナ オーケストレーション システムをサポートする必要があります。

開発者は CI/CD と検討中のツールを理解していますか?

CI と CD の原則は明白に思えるかもしれませんが、詳細はそうではありません。さまざまな CI/CD ツールには、さまざまなレベルのサポートとドキュメントがあります。 Jenkins について書かれた本は数多くありますが、これは最も古い本なので驚くことではありません。

その他の製品については、ツールを選択する際のデューデリジェンスの一環として、ドキュメントやサポート フォーラム、有料サポート オプションを調べることをお勧めします。

CI の一般的な背景については、Duvall らによる Addison-Wesley の書籍『Continuous Integration』を参照してください。同様に、CD の一般的な背景については、Humble と Farley の Continuous Delivery を参照してください。どちらの本も出版時にジョルト賞を受賞した。

プロジェクトごとに異なる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 CI/CD です。これは、オープンソースの Serverless Framework の拡張バージョンである Serverless Framework Pro の一部です。サーバーレス CI/CD はサーバーレス アプリケーションのデプロイ用に最適化されており、現在は AWS 上でのみ実行されます。アプリケーションを十分にサポートして使用できるかどうかを判断する必要があります。

コミットする前に概念実証を行う

CI/CD が完全に実装されると、それはインフラストラクチャの重要な部分になります。スピードを上げるときはこれを念頭に置いてください。

CI/CD パイプラインの展開を開始する前に、厳密な概念実証を実行することが重要です。 CD フェーズを開始する前に、まず CI 部分を置きます。 CI/CD パイプラインを本番インスタンスに接続する前に、必ずテスト スイートとロールバック機能を練習し、自動化が堅牢であることを確信できるまでプロセスに人間を関与させてください。

オリジナルリンク: https://www.infoworld.com/article/3620932/how-to-choose-a-cloud-based-cicd-platform.html