CI/CDツールの比較: Jenkins、GitLab CI、Buildbot、Drone、およびConcourse
紹介
継続的インテグレーション、デリバリー、およびデプロイメントは、開発のスピードと十分にテストされた使える製品のリリースを増加させるための戦略です。継続的インテグレーションは、開発チームが統合の対立を最小限に抑えるために、変更を早期に共有のコードベースにテストし、統合することを奨励します。継続的デリバリーは、この基盤の上に構築され、デプロイメントまたはリリースへの障壁を取り除きます。継続的デプロイメントは、テストスイートを通過したすべてのビルドを自動的にデプロイすることで一歩進んでいます。
上記の用語は主に戦略と実践に関するものですが、ソフトウェアツールは組織がこれらの目標を達成するのを助ける大きな役割を果たします。CI/CDソフトウェアは、チームが新しい変更を一連の段階を通じて自動的に進めるのを助け、フィードバックの時間を短縮し、プロセスからの摩擦を取り除くことができます。
このガイドでは、協力的なソフトウェア開発をより簡単にするために設計された人気のあるオープンソースの継続的インテグレーション、デリバリー、およびデプロイメントサーバーをいくつか比較します。Jenkins、GitLab CI、Buildbot、Drone、およびConcourseについて見ていきます。
ジェンキンス
Jenkinsは、最も早く登場したオープンソースの継続的インテグレーションサーバーの一つであり、現在でも最も一般的に使用されているオプションです。元々はHudsonプロジェクトの一部であり、OracleによるSun Microsystemsの買収後、商標の対立があったため、コミュニティとコードベースが分かれました。Hudsonは2005年に最初にリリースされ、Jenkinsとしての最初のリリースは2011年でした。
長年にわたり、Jenkinsはソフトウェア関連のタスクを自動化するための強力で柔軟なシステムに進化しました。Jenkins自体は主に自動化フレームワークとして機能し、その重要なロジックの多くはプラグインのライブラリを通じて実装されています。ウェブフックをリッスンしたり、リポジトリを監視したり、環境を構築したり、言語サポートを行ったりすることはすべてプラグインによって処理されます。このことは多くの柔軟性を提供しますが、CIプロセスは多くのサードパーティのプラグインに依存することになり、それが壊れやすくなる可能性があります。
Jenkinsのパイプラインワークフローは、プラグインを通じて提供される比較的最近の追加機能で、2016年から利用可能です。CIプロセスは、リポジトリ内のファイルやJenkinsのWeb UIのテキストボックスを使用して、Groovy言語を用いて宣言的または命令的に定義することができます。Jenkinsに対する一般的な批判の一つは、プラグイン中心の設定モデルとリポジトリの外でパイプラインやビルドプロセスを定義できる能力が、別のJenkinsインスタンスで設定を簡単に再現するのを困難にすることがあるという点です。
JenkinsはJavaで書かれており、MITライセンスの下でリリースされています。プロジェクトのためにJenkinsサーバーを構成するには、Ubuntu 16.04にJenkinsをインストールする方法についてのガイドに従ってください。
GitLab CI
GitLab CIは、Gitリポジトリのホスティングおよび開発ツールプラットフォームであるGitLabに組み込まれた継続的インテグレーションツールです。もともとは独立したプロジェクトとしてリリースされましたが、2015年9月にGitLab 8.0のリリースとともにメインのGitLabソフトウェアに統合されました。
GitLab CIにおけるCI/CDプロセスは、コードリポジトリ内のファイルでYAML構成構文を使用して定義されています。作業はランナーと呼ばれるマシンに送信され、これらは簡単に設定でき、さまざまなオペレーティングシステム上でプロビジョニングできます。ランナーを構成する際には、Docker、シェル、VirtualBox、Kubernetesなどの異なるエグゼキュータから選択して、タスクの実行方法を決定できます。
GitLab CIのGitLabリポジトリプラットフォームとの密接な統合は、ソフトウェアの使用方法に明確な影響を与えています。GitLab CIは、他のリポジトリホスティングプラットフォームを使用している開発者には選択肢ではありません。一方で、統合された機能により、GitLabユーザーは追加のツールをインストールして学ぶことなく、CI/CD環境をセットアップすることができます。自動テストは、ウェブインターフェースでいくつかのオプションを有効にし、ランナーマシンを登録し、リポジトリにパイプライン定義ファイルを追加することで開始できます。この密接な関係により、プロジェクト間でランナーを共有し、リポジトリ内で現在のビルド状況を自動的に確認し、それを生成したコードとともにビルドアーティファクトを保持することができます。
GitLabとGitLab CIはRubyとGoで書かれており、MITライセンスの下でリリースされています。GitLab CIを使用して継続的インテグレーションパイプラインを設定する方法についてのガイドに従うことで、GitLabサーバーでこの機能を構成する方法を学ぶことができます。
ビルドボット
Buildbotは、非常に柔軟性のある継続的インテグレーションフレームワークです。2003年にMozillaのTinderboxプロジェクトの代替として初めてリリースされ、Buildbotは主にさまざまなプラットフォーム上でのビルドテストの自動化を目的として設計されました。
BuildbotはGPLライセンスでリリースされ、Twistedライブラリを使用してPythonで記述されています。構成の簡素化のために基盤となる言語を抽象化するのではなく、Buildbotの構成は完全にPythonで記述されています。これは、構成が他のシステムに比べてかなり複雑になる傾向があることを意味しますが、管理者は理想的なワークフローやプロセスを設計するための余地が広がります。ビルドの各ステージは明確に分離され、プログラム可能です。Buildbotは、ウェブフレームワークがカスタムサイトを構築するのを可能にするのと同様に、独自のカスタムプロセスを構築するためのツールを持つフレームワークとしての地位を確立しています。
ビルドボットはビルドテストプラットフォームとしての歴史があるため、多くの異なるオペレーティングシステムとバージョン管理システムをサポートしています。同様に、オープンソースのテストを考慮して設計されているため、アーキテクチャはユーザーが好きなプラットフォームを持つワーカーをプロジェクトに簡単に提出できるようにしており、利用可能なテストベースを拡張することができます。ユーザーはシステムにいくつかのPythonパッケージをインストールし、プロジェクトに対する資格情報を提供するだけで済みます。
ビルドプロセスを自動化するためにBuildbotを使用し始めるには、Ubuntu 16.04にBuildbotをインストールする方法に関するガイドに従ってください。
ドローン
Droneは、コンテナファーストのアーキテクチャで構築された現代のCI/CDプラットフォームです。 上述のツールはすべてDockerを使用してビルドを実行するオプションを含んでいますが、コンテナベースのワークフローはDroneの設計の中心にあります。 DroneはGoで書かれており、2014年にApacheライセンスのもとで最初にリリースされました。
Droneは、Dockerとリポジトリプロバイダーの間の中間調整レイヤーとして機能します。CI/CDサーバーを起動してからバージョン管理システムホスティングサービスに接続するのではなく、Droneは最初にリポジトリアカウント情報を必要とし、自身の認証、ユーザー、権限モデルをブートストラップします。すべてのCIプロセスと同様に、Drone自体もコンテナとして実行されます。複数のデータベースバックエンドとリポジトリプロバイダーをサポートし、トランスポート暗号化のためにLet’s EncryptによるTLS/SSL証明書のセットアップをサポートするビルトイン機能があります。
Droneは、パイプライン定義のためにリポジトリ内の特別なYAMLファイルを探します。その構文は読みやすく、表現力豊かに設計されているため、リポジトリを使用する誰もが継続的インテグレーションプロセスを理解できるようになっています。Droneはプラグインシステムを提供していますが、それはJenkinsのものとは異なる使い方がされます。Droneでは、プラグインは特別なDockerコンテナであり、事前に構成されたタスクを通常のワークフローに組み込むために使用されます。これにより、全プロセスを手動でスクリプトするのではなく、いくつかのパラメータでプラグインを呼び出すことで一般的なタスクを達成しやすくなります。この意味で、Droneプラグインは、特定の狭い範囲のタスクをうまくこなすように設計されたUnixユーティリティコマンドに類似しています。
コミットを自動的にテストするためのDroneサーバーの設定方法を学ぶには、Ubuntu 16.04にDroneをインストールおよび設定する方法ガイドに従ってください。
協議会
Concourseは2014年に初めてリリースされた比較的新しい継続的インテグレーションプラットフォームです。ConcourseのCI/CD分野へのアプローチは、他のツールとは大きく異なり、可能な限り自らを方程式から取り除こうとし、状態を最小限に抑え、すべての外部要因を「リソース」と呼ばれるものに抽象化します。この哲学の目標は、同じプロセスをどのConcourseサーバーでも簡単に実行できるように、統合サーバーを完全に使い捨てにすることです。
継続的インテグレーションプロセスのすべての部分は、システムの異なる要素をモデル化する基本的なプリミティブから構成されています。プロセスの各部分は、その依存関係を明示的に定義します。たとえば、最初のタスクはVCSリポジトリへの最新のコミットを必要とする場合がありますが、プロセスの後半の部分は、以前のステージに合格した最新のコミットを必要とする場合があります。この各ステップの正確な依存関係をマップすることによってパイプラインを構築する方法は、厳密に定義された動作につながります。
プロセスから偶発的な状態をさらに取り除くために、Concourseはジョブ間で暗黙的に何も渡さず、ビルドアーティファクトを保存する内部的な方法も提供しません。次のステージで必要なすべての情報は明示的に定義される必要があり、外部ストレージにプッシュされて次のステップに取り込まれる必要があります。明示的な定義を要求することによって、Concourseはシステムが考慮しなければならない仮定や不明な変数の数を最小限に抑えることを望んでいます。
ConcourseはGoで書かれており、Apacheライセンスのもとでリリースされています。継続的インテグレーションプロセスを自動化するためのConcourseサーバーの設定方法を学びたい場合は、Ubuntu 16.04にConcourse CIをインストールする方法に関するガイドをチェックしてください。
結論
継続的インテグレーション、デリバリー、デプロイメントソフトウェアは、プロセスを信頼性が高く、繰り返し可能にするために設計された複雑な自動化システムです。上記の説明からもわかるように、自動テストとリリースをどのように最も効果的に実行するかについて、多くの異なるアイデアがあります。それぞれの方程式の異なる部分に重点が置かれています。単一のツールがすべてのプロジェクトのニーズを満たすことはありませんが、質の高いオープンソースのソリューションが多く利用できるため、チームのニーズを満たすシステムを見つけられる可能性が高いでしょう。