CI/CDの基礎知識

CI/CDの採用により、開発者とテスターがソフトウェアをリリースする方法が変わりました。CI/CDとは何でしょうか？CI/CDとは継続的インテグレーション（Continuous Integration）, 継続的デリバリー（Continuous Delivery） もしくは継続的デプロイメントイベント（Continuous Deployment)の略で、常に新しいコードを統合する文化やプロセスを表しています。
この記事では、CI/CDパイプラインへの移行について、開発者がより成功するためのさまざまなツールやプロセスの変更に関する洞察を提供します。

開発者のアプローチは常に変化しています。過去はウォーターフォール、その後はアジャイル、そして今はDevOpsです。DevOpsは、現代の開発者が優れた製品を構築する方法です。DevOpsの台頭により、継続的インテグレーション、継続的デリバリー（CI/CD）、継続的デプロイメントという新しい手法が生まれました。従来のソフトウェア開発およびデリバリー手法は、デプロイメントの頻度が増えるにつれて、急激に時代遅れになってきています。

CI/CDパイプラインの流れ

DevOps以前は、ほとんどの企業が月次や四半期ごと、隔年、あるいは年次リリースでソフトウェアをデプロイしていました（アジャイル時代とも呼ばれています）。現代のDevOpsの時代では、毎週、毎日、さらには1日に何度もデプロイすることが当たり前になっています。SaaSが開発の世界を席巻している現代では顧客に新しいコンポーネントをダウンロードさせることなく、その場で簡単にアプリケーションを更新することができます。CI/CDパイプラインが正しく機能していれば、アップデートが行われたことにさえ気づかないはずです。 

開発チームは、ソフトウェアデリバリパイプライン全体に自動化を導入することで、デリバリサイクルの短縮に適応しています。ほとんどのチームは、コードのチェックインと新しい環境へのデプロイのプロセスを自動化しています。これらの適応は、CI/CDプロセスを生み出し、ユニットテストを含むテストプロセスの自動化への焦点と結びついています。

CI/CDとは何か？用語解説

継続的インテグレーション（CI）は、個々の開発者のソフトウェア成果物をリポジトリに融合させることに焦点を当てています。これは1日に数回行うことができ、主な目的は統合バグの早期発見を可能にすると同時に、より緊密な結束とより多くの開発協力を可能にします。

継続的デリバリー（CD）の目的は、デプロイメントやリリースプロセスに内在する摩擦点を最小化することです。通常、チームの実装では、ビルド・デプロイの各ステップを自動化し、いつでも安全なコードリリースができるようにします。

継続的デプロイメント（CD）は、より高度な自動化であり、コードに大きな変更が加えられると自動的にビルド/デプロイメントが行われます。

これらの各段階は、デプロイメント（または開発）パイプラインの一部です。
「継続的デリバリー：ビルド、テスト、デプロイメントの自動化による信頼性の高いソフトウェアリリース」という本の中で、著者であるJez HumbleとDavid Farleyはソフトウェアに加えられたすべての変更が、「リリースされるまでに複雑なプロセスを経る」ことを説明しています。このプロセスには，ソフトウェアのビルドが含まれ，そのビルドが複数の段階のテストとデプロイメントを経て進行します。 これには、多くのメンバーと場合によっては複数のチームによるコラボレーションが必要です。

Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation

「デプロイメントパイプラインはこのプロセスのモデルであり、継続的インテグレーションとリリース管理ツールにおけるその進化形はバージョン管理から様々なテストとデプロイのセットを経てユーザーにリリースするまで、それぞれの変更の進捗を確認し管理することを可能にするものです 」とJez Humble とDavid Farley述べています。

継続的インテグレーション(CI)

継続的インテグレーションを実践する場合、開発者は自分のコードを共通のリポジトリのメインブランチに統合することが頻繁にあります。機能を個別に構築し、サイクルの終わりにそれぞれを提出するのではなく、開発者は一日に何度もソフトウェア成果物をリポジトリにアップできるようになります。

CIは、開発者が通常行うよりも頻繁に、かつ早期に統合を行うことで、統合コストを削減するというのが主な考え方です。実際には、開発者は統合時に新しいコードと既存のコードの境界の衝突を発見することがよくあります。もし、早期に頻繁に統合が行われれば、これらのコンフリクトを解決することが容易になり、より少ないコストで実行できると期待されます。

もちろん、トレードオフがあります。すなわち、このプロセスの変更によって、品質保証が追加されるわけではありません。多くの組織では、このような統合は、時間的なコストが高くなることが分かっています。 それは、新しいコードが新しいバグを発生させず、既存のコードを壊さないことを保証するために、手作業に頼っているからです。統合作業中の摩擦を減らすために、継続的インテグレーションは、テストスイートと自動テスト実行に依存しています。自動テストと継続的テストは全く異なるものであることを認識することが重要です。

CIの目標は、統合をシンプルで簡単に繰り返せる日常的な開発タスクに磨き上げ、ビルド全体のコストを削減し、サイクルの早い段階で不具合を明らかにすることです。CIが成功するかどうかは、開発チームのカルチャーに依存しています。特に、頻繁にビルドを繰り返すインセンティブがあるかどうか、バグが頻繁に見つかったときに熱心に対処しようとするかどうかにかかっています。このような面を持続させるためには、チームカルチャーに変化をもたらす必要があるかもしれません。

継続的デリバリー(CD)

継続的デリバリーとは、CIを拡張したものでソフトウェアデリバリープロセスをさらに自動化し、いつでも簡単かつ確実に本番環境にデプロイできるようにしたものです。

成熟した継続的なデリバリープロセスでは、常にデプロイ可能なコードベースが示されます。CDでは、ソフトウェアのリリースは、不安や緊急性を伴わない日常的なイベントとなります。チームは、手の込んだオーケストレーションや特別なテストなしで、いつでもデプロイ可能な本番レベルのリリースを構築できるという確信を持って、日々の開発作業を進めることができます。

CDは、チームがテストとデプロイのプロセスを自動化するセントラルなデプロイメントパイプラインに依存しています。このパイプラインは、ビルドに対してテストスイートのセットを段階的に実行する自動化されたシステムです。CDは高度に自動化されており、一部のクラウド環境では、簡単に設定することができます。

パイプラインの各セグメントでは、ビルドがクリティカルなテストに失敗することがあり、その場合はパイプラインがチームにアラートを発します。そうでない場合は、ビルドは次のテストスイートに進み、テストに連続してパスすると、パイプラインの次のセグメントに自動的に移行します。パイプラインの最後のセグメントでは、ビルドを実稼働環境と同等の環境に配備します。これは包括的な活動であり、ビルド、デプロイ、および環境のすべてが一緒に演習されテストされるからです。その結果、実際の本番環境に自信を持って配備し、検証可能なビルドができあがります。

最新のCI/CDパイプラインの確かな例は、AWSで見ることができます。Amazonはクラウドコンピューティングプロバイダーの1つで、CI/CDパイプラインの素晴らしい環境を提供しています。

継続的デリバリーは、リポジトリへのコードの登録から、完全にテストされ適切に機能するビルドを本番環境にリリースするまでの全ステップを自動化するため、多くの人が魅力的だと考えています。CDはビルドとテストのプロセスを精巧に自動化しますが、いつ、どのように、そして何をリリースすべきかの決定は、依然として手作業で行わなければなりません。継続的デプロイの他のすべてのステップを自動化することで、これらの議論のための時間から解放されることができます。

継続的デプロイメント

継続的デプロイは、継続的デリバリーを拡張したもので、ソフトウェアのビルドがすべてのテストに合格すれば、自動的にデプロイされるようにしたものです。このようなプロセスでは、いつ、何が本番環境に入るかを人が決める必要はありません。継続的デプロイメントを備えたCI/CDシステムの最後のステップは、ビルドコンポーネントやパッケージがデリバリーパイプラインを正常に終了した場合に、自動的にデプロイされるものです。このような自動デプロイは、コンポーネント、機能、および修正を顧客にスピーディーにデリバリーし、何が本番環境にプッシュされたかを正確に把握できるように構成することができます。

継続的デプロイメントを採用している組織では、ユーザーが新しいデプロイメントに対して迅速にフィードバックを与えることができるため、非常に大きな利益を得ることができます。役に立たない機能や誤解している機能に対するユーザーの素早い反応は、チームの集中力を高め、投資に対する良いリターンが期待できない機能分野にこれ以上労力を割くことを避ける助けになります。しかし、機能が迅速にユーザーに提供されるため、明らかになった不具合は迅速に対処する必要があります。そうしないと、チームは最新のバグを修正し、新しい機能をリリースするために過負荷になる危険性があります。

CI/CDツール

DevOpsへの移行に伴い、CI/CDパイプラインを支援する新しい自動化ツールが急増しています。これらの自動化ツールは通常、GitHubのようなコードリポジトリシステムやJiraのようなバグトラッキングシステムなど、様々な定評ある開発者向けツールと統合されています。SaaSがより一般的なデリバリーモデルになったため、これらのツールの多くは、現代の多くの開発者がアプリを実行しているのと同じ場所であるクラウドで実行されています（mablの開発者も！）。

よく使われている自動化ツールはJenkins（旧Hudson）で、数百人の貢献者と商用企業のCloudbeesによってサポートされているオープンソースプロジェクトです。Cloudbeesは、いくつかの異なるJenkinsトレーニングプログラムと製品アドオンを提供しています。

オープンソースプロジェクト以外にも、CircleCI、Codeship、Shippableなど、最新の商用ソフトウェア自動化製品がいくつかあります。これらはそれぞれ、特定のワークフローに対していくつかの異なる利点と欠点を持っています。どれが自社に合っているかを本当に理解するには、開発者のワークフロー内でそれぞれを具体的に試し、自分の環境（ツール、クラウドプラットフォーム、コンテナシステムなどとの連携）でどう動くかを確認することをお勧めします。

私たちはGoogle Cloud Platform上でmablを構築しているので、GCPと互換性があり、できれば統合されている製品を探していました。CircleCI、Codeship、Shippableを見て、それぞれの長所と短所を比較検討しました。

次のステップとは？

最新のCI/CDパイプラインをデプロイしたら、開発者のワークフローにおける既存のツールやプロセスも最新化する必要があることに気づくでしょう。その中で多くの注意を払う必要があることにすぐに気がつくのは、テストです。Logz.ioのブログで、John Fahl氏は、CDに到達するための真の鍵は、迅速なリリーススケジュールに自信を持たせる豊富なテストを作成することであると述べています。もしあなたのチームが毎日、あるいは一日に何度もデプロイを行っていて、現在のテストプラクティスが実行に何時間もかかったり、夜間に実行するように設定されているとしたら、テストはデプロイについていけなくなります。mablは、このような問題を解決することを目的としています。

CI/CDの進化

CI/CDのコンセプト、開発哲学、プラクティスはほとんど変わっていませんが、CI/CDパイプラインを支えるツール（CI/CDの未来の原動力）は進化を続け、新しい方向へと枝分かれしてきました。これらの進化は、Kubernetes の人気の高まりや、コンテナ利用の増加によるコンテナに接続するツールの革新など、チームがパイプラインに使用するサービスの種類の増加を見越した結果、またはそのような理由からもたらされたものです。

Jenkins XはJenkinsのサブプロジェクトとして提案され、JenkinsのコアエンジンとKubernetesなどのオープンソースツールを使ってクラウド向けのCI/CDを自動化することに焦点をあてています。X は「セマンティックバージョンによる自動リリース、成果物、Docker イメージ、Helm チャートの作成、GitOps によるバージョン管理された成果物の環境間での自動プロモーション、Pull Request ごとのプレビュー環境の作成」[CloudBees ソース] を可能にするよう設計されています。公開以来、あまり話題になっていませんが、開発はまだ続いており、チームはXの狙いを振り返る1周年記念ポストを発表しています。

パイプラインの継続的デリバリーもアップグレードされるかもしれません。Harness というツールは、デプロイメントがプッシュされた後にそれを追跡して安全性を強化することを目的としています。パイプラインの構築プロセスを簡素化するパイプラインビルダーとワークフローウィザードに加え、Harnessには継続的な検証機能があり、チームが送信したデプロイメントが新たな異常やリグレッションを引き起こしていないか継続的にチェックします。デプロイに失敗した場合は、ユーザーの操作を必要とせず、アプリの最新バージョンへのロールバックが自動化されます。最近、Harnessの開発チームは、デプロイの数時間後やユーザーのトラフィックが平均より多いときにこれらの異常が表面化した場合に備えて、この機能を24時間365日実行するように拡張しました。

コミットからデプロイまでのパイプラインの自動化に注力するCI/CDプラットフォームとして定評のあるCircleCIは、11月にOrbsをリリースし、チームがワークフローを共有する能力を向上させました。Orbs は CircleCI の新しいパッケージマネージャで、「ソフトウェアデリバリ自動化の構成に特化して設計」されています。（CircleCI のソース）Orbs を使うことで、CircleCI ユーザーは CI/CD ワークフローを構成するコマンド、エグゼキュータ、ジョブを簡単にパッケージ化し、好きなチームに送信することができます。これらのチームは、全く同じワークフローを使用することも、ニーズに合わせてそれらを微調整することもでき、同じプロジェクトのチームのための新しいCI/CDワークフローのセットアップを著しくスピードアップさせることができます。CircleCI は、一般的なパイプラインの標準化されたOrbsをリリースしたため、個々のチームが多くのドキュメントやセットアップガイドがある一般的なツールを使用して CI/CD を簡単に開始することができるようになりました。

どんな機能か見てみませんか？

mablは、CI/CDのために構築されたインテリジェントなテスト自動化ソリューションです。mablのテスト自動化がCI/CDパイプラインにどのように統合されるかを見るには、今すぐ無料トライアルをお試しください。