CI/CDツールは、今日のアジャイルなコンテナー主導のソフトウェア生産サイクルで重要な役割を果たしています。この「非常にわかりやすい」概要は、CI/CDツールの基礎を知るのに役立ちます。

かつてウォーターフォールが主なソフトウェア開発手法だった時代には、1つのソフトウェアプロジェクトに数か月から数年もの期間がかかることもありましたが、アジャイル手法のおかけで、プログラミングのサイクルは数日から数週間にまで短縮されました。

しかし、数週間というのも昔の話で、今日のDevOps主導の世界では、継続的インテグレーション、継続的デリバリ、および継続的デプロイ(CI/CD)を使用して、数日から数時間でプログラムが更新されています。たとえばNetflix社は、自社のCI/CDパイプラインを使用して、コードのチェックインから複数の地域への展開に至るまでのプログラムの移動を30分未満で完了させています。

今では、これほどにまでサイクルが短縮されているのです。

自動化はCI/CDプロセスの重要な要素であるため、当然のことながら、タスクの管理をサポートすることを目的としたツールはいくつか存在します。まず、広く普及しているいくつかのCI/CDツールを概説する前に、CI/CDの基礎を振り返ってみましょう。

 

CI/CDの仕組み: 簡単なおさらい

継続的インテグレーション(CI)では、開発者が早い段階から頻繁に、コードを共有コードレポジトリのメインブランチに統合しますが、その目的は、できるだけ早く問題に対処して開発コストを抑えることにあります。

CIでは、ソフトウェアを単独で記述してから開発サイクルの最後に大規模なシステムにマージするのではなく、一般的には、1日に複数回コードを統合します。そのためプログラマは、比較的簡単にコードを修正しながら、コードの不一致などの問題を解決できます。

こうした作業を手動で行うと、信じられないほど時間がかかって面倒ですが、CIでは、事実上ほぼすべての手順で自動テストスイートが使用されており、コードをマージできる段階になると、自動化されたプロセスによって新しいコードベースの構築が開始されます。また、バグをチェックするために一連の品質保証テストが自動的に実行され、アップデートによって統合の問題が発生しないかどうかが確認されます。

CIの次のステップである継続的デリバリ(CD)でもリリースサイクルが自動化されますが、これは、ソフトウェアが自動テストに合格したタイミングで新しいアプリケーションバージョンが展開されることを意味します。たとえば、カナリアリリースと呼ばれるテストでごく一部のユーザーにアプリケーションをロールアウトすると、それらのユーザーの承認を得た後、システムによって本番環境にソフトウェアがリリースされます。

最後に、継続的インテグレーションと継続的デリバリのプロセスが確立されたら、IT部門は継続的デプロイの導入を進めることができます。継続的デプロイでは、新しいコードがパイプラインと呼ばれるプロセスで継続的にユーザーにリリースされ、本番環境のパイプラインの自動テストに合格したすべての変更が自動的にリリースされるようになりますが、これは、リリース日やPatch Tuesday (定例パッチ公開日)がなくなることを意味します。何も問題が起きなければ、コードはプログラミング、テスト、リリースへとスムーズかつ自動的に移行します。

これらのすべてを可能にし、「何も問題が起きない」ようにするには、適切なツールが必要です。ではここから、いくつかの最も有名なツールを紹介します。

 

Jenkins

何らかのCIツールを知っているのであれば、それはおそらくJenkinsではないかと思います。このCloudBees社がサポートするオープンソースプログラムは、最も古く、最高のものと考えられているCIプログラムの1つです。また、約200万人が利用するJenkinsは、最も広く導入されているCIプログラムでもあります。

Jenkinsは、GUIインターフェイスとコンソールのコマンドの両方で構成できるクロスプラットフォームCIツールであり、JenkinsのCIプロセスは、Groovy言語を使用して宣言的または命令的に定義することも、JenkinsのWebユーザーインターフェイスを使用してテキストボックスで定義することも可能です。

Jenkinsは、柔軟性が高いことで知られていますが、その理由は主に、プラグインの追加のしやすさとそれを可能にする機能にあります。ただしこれには、メリットもデメリットもあり、Webフックの受信やレポジトリの監視からDockerのサポートに至るまでのすべてが、プラグインを使用して行われるため、Jenkinsが脆弱であると考えているDevOpsの担当者もいます。

Javaで記述されるJenkinsは、SunとOracleのHudsonの派生プロジェクトとして2011年に開始され、MITライセンスでリリースされました。

サーバーでJenkinsを実行したくない場合は、CloudBees社から提供されているホスト型ソリューションを利用できます。また、同社から包括的な分析プラットフォームも提供されていますが、他にも選択肢はあり、Jenkinの大規模なオープンソースコミュニティから高度な分析機能やダッシュボードを入手することも可能です。

1,400を超えるプラグインが用意されているJenkinsは柔軟性が高く、サポートも充実しているため、試してみる価値はあります。Jenkinsは、GitHubのビルドと統合できることで特に人気がありますが、考えられるほぼすべてのCI/CDのジョブで使用することが可能です。

 

Buildbot

Buildbotは、長年使用されてきた人気のCIフレームワークであり、その歴史は、Mozillaが使用を開始した2003年にまで遡ります。MozillaがTaskclusterを支持したことでBuildbotの価値は下がりましたが、この古くからのツールは今もなお、Chromium、GNOME、WebKitといった、その他の著名なオープンソースプロジェクトで使用されています。Buildbot自体はTwisted Pythonのライブラリで記述されており、GPLv2でライセンスが付与されています。

Buildbotのインストールは、1つか2つのマスターと複数のワーカーで構成されています。マスターは、ソースコードレポジトリの変更を監視してワーカーのアクティビティを調整し、ユーザーと開発者に結果を報告します。ワーカーは、主要なオペレーティングシステムとバージョン管理システムのすべてで動作します。

Buildbotを構成するときは、Pythonの構成スクリプトをマスターに提供します。これらのスクリプトは、組み込みのコンポーネントを使用して簡素化したり、Pythonで拡張したりできるため、Pythonユーザーに利用されることが多いうえ、Pythonを知らなくても短期間で習得できます。

本来ジョブスケジューリングシステムであるBuildbotは、主に幅広いプラットフォームのビルドテストを自動化する目的で使用するものですので、それだけが必要なのであれば、ぜひ検討してみてください。ただし、他にも必要なものがあるのなら、この続きもご覧ください。

 

CircleCI

CircleCIツールは、その処理の速さで高い評価を受けています。CircleCIでは、ビルドをキャッシュし、複数のマシンで同時にテストを実行できるため、最終的にテストの時間が短縮されます。また、クラウドで実行したり、オンプレミスバージョンとして実行したりできるという点でも高く評価されています。

ほぼすべてのオペレーティングシステム、またはクラウドで使用できるCircleCIは、AJAXとHTML5を多用するシングルページWebアプリケーションです。CircleCIでは、Windowsアプリケーションを構築することはできません。また、Dockerで.NET Coreを使用してアプリケーションを構築することは可能ですが、決してWindowsの構築またはテストを完全にサポートしているとは言えません。

このプログラムは、ユーザービリティの点で高い評価を受けており、これについて、Forrester社はあるレポートの中で次のように説明しています。「すぐに使用できるYAML Ain't Markup Language (YAML)のサンプルが含まれており、次のステップを示すガイド機能も付いたCircleCIのセットアップウィザードは、開発者にとって最も使いやすいプロジェクト構成用のツールの1つです。これを使用したお客様は、ビルドの通知とアラートを簡単かつ柔軟に設定できることに感動していました」。また、それ以外のメリットとして、セキュアシェル(SSH)を介して提供されるビルドに依存しない機能、ワークフロー、Dockerのサポートなどが挙げられます。

CircleCIのビルド構成は、各プロジェクトのルートディレクトリにある、circle.ymlと呼ばれるファイルに保存され、CircleCIの構成は、CIの構成を他のソースコードのように扱うことで、簡単にバックアップしたり共有したりできます。

さらに、CircleCIは、Slack、HipChat、IRCなどの他の一般的な開発者ツールだけでなく、Code ClimateやSauce Labsといったテストツールとも連携し、ビルドのステータスが変わった場合にのみ通知を行うオプションも用意されています。

これはオープンソースプログラムではありませんが、CircleCI社によると、CircleCIではオープンソースプロジェクトを構築することが可能です。

オープンソースやWindowsにこだわっているのであれば、CircleCIを使用する必要はありませんが、そのようなことがなく、テストを高速化する必要に迫られているのなら、CircleCIを検討する価値はあります。

 

Spinnaker

Netflix社は、CI/CDに関して豊富な知識と経験を有しています。同社の継続的デプロイツールであるSpinnakerは、一連のDockerコンテナーをベースとするマイクロサービスアプリケーションです。このSpinnakerが登場したことにより、2014年以降、テレビへの「Stranger Things」や「The Unbreakable Kimmy Schmidt」などの配信が常にスムーズに行われるようになりました。

Spinnakerは、Docker SwarmかKubernetesのクラスターで開発し、テンプレートを使用して、Amazon Web Services (AWS)、Azure、およびGoogle Cloudでセットアップすることが可能です。Spinnakerでは、バイナリやコンテナーイメージといったアプリケーションアーチファクトをパッケージ化できます。またSpinnakerは、JenkinsやCircleCIなどの他のCIツールと組み合わせて使用することも可能なため、1つのツールで標準化することを望まない企業に適したオプションと言えます。ただし、数多くのメリットはあるものの、Spinnakerはビルドツールではなく、テスト/デプロイツールであるということを知っておく必要があり、ビルド部分は、JenkinsなどのCIツールで処理されます。

とはいえ、SpinnakerにはCDの面で注目すべきポイントがあり、その前身である、AWS上で固定されていたAsgardとは違って、Spinnakerは、マルチクラウドアプローチとプラガブルアーキテクチャーを売りにしています。

Google社はNetflix社と手を組み、共通の目標を掲げてオープンソースのSpinnakerを開発しました。Google社のプロダクトマネージャーであるChristopher Sanson氏が説明しているように、「すぐに使用できるSpinnakerは、カナリアリリース、複数のステージング環境、Red/Black (またはBlue/Green)デプロイ、トラフィック分割、簡単なロールバックなどの高度なデプロイ戦略をサポートしています」。

これにより、Spinnakerは、特にすべてのサーバーで非常に短時間のうちにアプリケーションをテストして展開するのに適したツールとなっていますが、Netflix社はSpinnakerを使用して、驚くほど頻繁にソフトウェアを更新しています。

Spinnakerの特に大きなメリットは、ほぼすべてのプラットフォームを幅広くサポートしている点にあります。Spinnakerは現在、AWS EC2、Kubernetes、Google Compute Engine、Google Kubernetes Engine、Google App Engine、Microsoft Azure、およびOpenStackで稼働していますが、もうすぐOracle Bare MetalとDC/OS (データセンターオペレーティングシステム)もサポートする予定です。また、Apache 2のライセンスを受けているSpinnakerのオープンソースコードを使用することも可能です。

 

Zuul

Zuulは、2012年以降日常的に使用されてきたオープンソースのCI/CDプログラムですが、Zuulの開発者は、当時のオープンソースのOpenStackクラウドプログラムで社内のCI/CDシステムとしてZuulを使用していたため、目に触れることがなかったのかもしれません。OpenStackは当初、Jenkinsを使用してCIの実現に向けた取り組みを開始しましたが、複雑なマルチプロジェクトのニーズに対応するために、より高度なツールが必要であると判断しました。

ご存知ないかもしれませんが、OpenStackは50を超えるオープンソースプログラムで構成されており、複数のコントリビューターから提供される膨大なコンポーネントを管理するのは、容易ではありませんでした(そして今も容易ではありません)。

Zuulプロジェクトは、multi-repo gating (マルチレポジトリゲーティング)に重点を置いています。この手法では、Zuulによって自動的に変更のテストが正しい順序で並行して行われるようになり、CIのプロセスが高速化されるため、開発者は変更がコードレポジトリに反映されるまで非常に長い時間待つ必要がありません。

Zuulは、1つずつテストしているかのように変更のテストが正確かつ厳密に行われるようにすると同時に、ゲーティングのためのテストジョブを並列実行できる、依存関係にあるパイプラインマネージャーを使用してこれを実現しますが、そのためにテストジョブを投機的に実行します。Zuulは、すべてのジョブが成功すると仮定したうえで、それらを同時にテストします。そして実際にジョブが成功すると、すべてのコードをマージできるため、ソフトウェアの統合が確実に迅速化されます。

ただし、1つのコードスニペットで問題が発生するとバッチの再検査が行われ、問題があった変更を除いて、成功すると見込まれていた変更が再度テストされます。そして最悪の場合、変更が1つずつテストされることになります。このような理由から、Zuulは大規模で複雑なプロジェクトの処理に最適なツールとなっています。

最近、The OpenStack Foundationによって主要なOpenStackプロジェクトからスピンアウトされたZuulは、オープンソースであり、Apache 2でライセンスが付与されています。現在複雑なプロジェクトを扱っているのであれば、時間を取ってZuulの機能を調べてみてください。

 

CI/CDの未来

この記事はすべてを網羅しているわけではなく、CI/CDツールは他にも数多くあります。

最適なツールを決定する前にプロジェクトの内容を確認し、これからの時代に本当に必要なものを検討してください。たとえば、Zuulは大部分のプロジェクトで必要とされないほど高度なツールであり、Spinnakerなどは、テストやデリバリに最適なツールではあるものの、統合には向いていません。

• ツールを検討する前に、どの機能が必要なのかを見極めます。既存のCIシステム向けのCDツールが必要なのであれば、CIを得意とするJenkinsに投資しても意味はありません。
• セルフホスティングを望んでいるのか、またはクラウドベースのサービスを使用したいのか、自社のデータストレージに関してどのようなルールが設けられているのか、そしてどちらが予算に見合っているのかを考えます。セルフホスティングを選択する場合は、それを担当するDevOpsチームを社内に置く必要がある点に留意しなければなりません。
• 現場の他のメンバーがそれらのサービスをどう思っているのか、ビジネスにおいてすでに最善であるとされているCI/CDツールがあるのかを確認します。また、Kubernetesに関しては、CI/CDに「最適なツールセットなどない」という事実を受け入れなければなりません。どのケースでも、自社に最適なツールを見つけるには、数多くのテストを行う必要があります。

CI/CDのベストプラクティスはまだ確立されておらず、それらをサポートするツールに関しても同じことが言えます。しかし、今後市場で最善のCI/CDツールが明らかになり、DevOpsで活用されるようになるのに伴って、大きな変化が起きるのではないかと思います。

CI/CDの象徴となっているNetflix社が、数時間で統合、テスト、デリバリを完了できる一方、大部分の企業は、このレベルの効率とは程遠い状況にありますが、ビジネスメリットを考えると、そこを目指すだけの価値はあります。

CI/CDは最終目標ではありません。ただし、CI/CDとビジネス目標を組み合わせれば、ソフトウェアを提供するまでの時間だけでなく、利益の面でも大きな改善が見られるようになるはずです。

 

CI/CDツール: リーダーのためのアドバイス

• 重要なCI/CDプログラムは数多くありますが、今のところ、真のマーケットリーダーは存在しません。ビジネスニーズに最適なプログラムを見つけるには、いくつかのプログラムを試してみる必要があります。
• CI/CDツールを決定する前に、自社のCI/CDのニーズを分析する必要があります。そのためには、開発チームと緊密に連携しなければなりません。