CIの近代化。ベストプラクティスと課題

継続的インテグレーション（CI）を近代化することは素晴らしいことですが、回避すべき重要な課題と、確実に成功するためのベストプラクティスがあります。

CIが進化するにつれて、より成熟したCIのアプローチに適したプラクティスがあります。成熟したCIの実践は、スピード、アジリティ、シンプルさを可能にし、自動化された方法で結果を普及させることができるはずです。

この記事は、私たちのeBook「Modernizing Continuous Integration」からの抜粋を含んでいます。気に入った内容があれば、eBookの全文を最後までご覧ください。無料です。

CIのベストプラクティス

自動化されたビルドを高速に保つ

ビルドは終日行われるため、エンジニアの効率化の核は高速で自動化されたビルドです。ビルドを外部化するとエンジニアのマシンやローカル環境をビルドのために拘束する必要がなくなり、エンジニアはビルドが発生するたびに前進や調整を続けられるようになります。簡単に言えば、ビルドが迅速であればあるほど、CDソリューションによってフィードバックを迅速に実装したり、リリース候補を作成してデプロイしたりすることができます。

全てのコミットは自動でビルドされるべき

ソフトウェアエンジニアにとって、共有リポジトリーでのコミット（あるいはマージ）は、ソフトウェア開発のライフサイクルを前進させる合図です。コミットとは、開発したものを試し始める準備ができていると約束することです。CIでは、各コミットを潜在的なリリース候補として扱い、成果物の構築を開始することが中核となります。これにより、デプロイを決定する際のリードタイムを短縮することができます。

小さなピース

マイクロサービスやCIでは、小さなピースが複雑さを軽減するのに役立ちます。ビルド、テスト、パッケージ、パブリッシュなど、より小さく機能的に独立したピースを持つことで、問題やボトルネックの特定がより容易になります。機能領域のいずれかに変更があった場合、その変更を微調整し、CIプラットフォーム内のステップを更新することができます。より小さなピースだと、特定のピースが他のシステムで実行される必要がある場合、機能を移行するための境界線を見つけることが容易となります。

結果の透明性を確保する

ソフトウェア開発ライフサイクルにおいてフィードバックは非常に重要であり、エンジニアのローカル環境から初めて変更が出るのは、ほとんどの場合、CIプロセス／プラクティスによるものです。ビルドとテストの結果を明確、簡潔、かつタイムリーにチーム全体に伝えることは、エンジニアリングチームが調整し、成功するリリース候補に向けて前進するのに役立ちます。最初のビルドは、イテレーションが発生するため、複数回実行されることが予想されます。CIプラットフォームによって、特に結果の共有に関する実装が異なる場合があります。 

CIと継続的デリバリー（CD）の違い

ソフトウェアを提供することは、継続的な意思決定と見なすことができます。アイデアを安全な方法で本番稼動させるには、テストと承認という形で信頼性を高める練習をし、カナリアデプロイメントのような安全なメカニズムでデプロイすることが必要です。CDとは、ユーザーに変更を自動で提供する機能です。CDには、モニタリング、検証、変更管理、通知／ChatOpsなどの自動化プラクティスが含まれ、分野横断的なものです。デプロイするための成果物がなければ、デプロイはできません。CIは、デプロイするための成果物を提供します。しかし、CIにも課題がないわけではありません。

CIの課題

ビルドとリリース候補は、新しい言語、パッケージング、アーティファクトのテストパラダイムなど、開発技術の進歩に密接に追随するため、CIを実装して機能を拡張することは困難です。コンテナ化技術の導入により、ビルドに必要な火力と速度は増加しました。

CIプラットフォームのスケーリング

「全てのコミットがビルドの引き金になるべき」というマントラに合わせてビルドの速度が上がると、開発チームでは、チームメンバー１人当たり１日に数回のビルドを生成する可能性があります。最新のコンテナ化されたビルドを生成するのに必要な火力は、従来のアプリケーションパッケージと比較して年々増大しています。

分散型CIプラットフォームを実行するために必要なインフラは、大量の計算を必要とするため、構築するアプリケーションと同じくらい複雑なものになる可能性があります。ローカルのビルドとテストのサイクルで、ローカルマシンのリソースがどれだけ消費されるか見てみましょう。これに、チームや組織の人数をかけてみてください。分散ビルドランナーは、複雑になりやすい分野のひとつです。新しいビルドノードをいつスピンアップし、いつスピンダウンするかの管理は、プラットフォームやエンドユーザーによって異なります。
 

テクノロジーの進化に対応するために

「テクノロジーにおいて唯一不変なものは、変化である」という格言は真実です。新たな言語、プラットフォーム、そしてパラダイムは、技術の進歩に伴って予想されることです。新しい技術を異種混在ビルドに含めたり、新しいテストパラダイムを受け入れたりすることは、一部の技術向けに設計された硬直したレガシーなCIプラットフォームでは難しいかもしれません。

自前やレガシーなCIプラットフォームは、プラットフォームが構築された時点で企業内にあったもの向けに設計されているという点で、非常に硬直化しやすいと言えます。新しい技術やパラダイムは、ビルドのための新しい依存関係や、新しいテスト手法の実装を必要とします。新しい依存関係の追加は、開発者が自分のローカルマシンで経験するのと同じくらい簡単であるべきです。例えば、必要なものを単に宣言するだけで、規約や宣言ベースのツールが依存関係を解決してくれます。レガシーまたは硬直したアプローチやプラットフォームでは、技術的な速度を維持するために必要な依存関係の管理が大きな負担となります。

CIプラットフォームをCDに拡張する

開発パイプラインの一部を自動化した最初のシステムであるため、ソフトウェアを本番環境に導入するための自動化を構築し続けることは自然な傾向でしょう。しかし、ユニットテストの失敗によるビルドの失敗は、複数のデプロイメントやリリース戦略を扱うこととは異なることに、組織はすぐに気づきます。デプロイの失敗は、システムを稼働していない状態にする可能性があります。これが、CI（ビルド）とCD（安全な本番環境でのデプロイ）の間に境界線を設けるべき理由です。

カナリアリリースなどの安全なリリース戦略を持ちながら、インフラとアプリケーションを一緒に作成しテストするために必要な厳密さは、合格／失敗のシナリオを決定するために、アプリケーションに関するチームの知識を体系化する必要があります。アプリケーションを追加する負担は大きく、ビルドを高速に保つなど、CIのベストプラクティスに反する可能性があります。

結論

CIの近代化に関するeBookの抜粋をお楽しみいただけたでしょうか。次回の抜粋では、CIをどのように近代化するか、そして近代的なインフラとはどのようなものかについて説明します。

次のブログ投稿まで待てない方は、今すぐeBook「Modernizing Continuous Integration」をダウンロードしてください。無料です。

この記事はHarness社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。