CI / CDツールの比較:Jenkins、GitLab CI、Buildbot、Drone、およびConcourse

前書き

https://www.digitalocean.com/community/tutorials/an-introduction-to-continuous-integration-delivery-and-deployment [継続的な統合、配信、および展開]は、開発の速度を向上させ、十分にテストされた使用可能な製品のリリース。 継続的な統合により、開発チームは変更を共有コードベースにテストし、早期に統合して、統合の競合を最小限に抑えることができます。 継続的な配信は、展開またはリリースへの道の障壁を取り除くことにより、この基盤から構築されます。 連続展開は、テストスイートに自動的に合格するすべてのビルドを展開することにより、さらに一歩進みます。

上記の用語は主に戦略と実践に関するものですが、ソフトウェアツールは組織がこれらの目標を達成できるようにする上で大きな役割を果たします。 CI / CDソフトウェアは、チームが一連の段階を経て新しい変更を自動的に進めることを支援し、フィードバックにかかる時間を短縮し、プロセスから摩擦を取り除きます。

このガイドでは、共同ソフトウェア開発を容易にするために設計された、人気のある無料およびオープンソースの継続的統合、配信、展開サーバーを比較します。 Jenkins、GitLab CI、Buildbot、Drone、およびConcourseを見ていきます。

ジェンキンス

Jenkinsは、最も初期のオープンソースの継続的統合サーバーの1つであり、現在も最も一般的な選択肢です。 もともとhttp://hudson-ci.org/[Hudson]プロジェクトの一部でしたが、コミュニティとコードベースは、元の開発者であるSun Microsystemsを買収した後、Oracleとの商標権の競合により分裂しました。 ハドソンは当初2005年にリリースされましたが、ジェンキンスとしての最初のリリースは2011年に行われました。

長年にわたり、ジェンキンスはソフトウェア関連のタスクを自動化する強力で柔軟なシステムに進化してきました。 Jenkins自体は、プラグインのライブラリを介して実装される重要なロジックの多くを備えた自動化フレームワークとして主に機能します。 Webフックのリッスンやリポジトリの監視から環境の構築、言語サポートまで、すべてがプラグインによって処理されます。 これによりかなりの柔軟性が得られますが、CIプロセスは多数のサードパーティプラグインに依存するようになる可能性があります。

Jenkinsのパイプラインワークフロー(プラグインを介して提供される)は、2016年から利用可能な比較的新しい追加機能です。 CIプロセスは、リポジトリ自体内のファイルで、またはJenkins Web UIのテキストボックスを使用して、http://groovy-lang.org/ [Groovy言語]を使用して宣言的または命令的に定義できます。 Jenkinsの一般的な批判の1つは、プラグイン中心の構成モデルと、リポジトリの外部でパイプラインを定義したりプロセスを構築したりする機能により、別のJenkinsインスタンスで構成を簡単に複製することが困難になる場合があることです。

JenkinsはJavaで記述され、MITライセンスの下でリリースされています。 Ubuntu 16.04にJenkinsをインストールする方法のガイドに従って、プロジェクトにJenkinsサーバーを構成します。 。

GitLab CI

GitLab CIは、gitリポジトリホスティングおよび開発ツールであるhttps://about.gitlab.com/[GitLab]に組み込まれた継続的統合ツールです。プラットフォーム。 もともとスタンドアロンプ​​ロジェクトとしてリリースされたGitLab CIは、2015年9月のGitLab 8.0のリリースでメインのGitLabソフトウェアに統合されました。

GitLab CIのCI / CDプロセスは、YAML構成構文を使用して、コードリポジトリ自体のファイル内で定義されます。 その後、作業はランナーと呼ばれるマシンにディスパッチされます。ランナーはセットアップが簡単で、多くの異なるオペレーティングシステムでプロビジョニングできます。 ランナーを構成するときに、Docker、shell、VirtualBox、Kubernetesなどのさまざまなエグゼキューターから選択して、タスクの実行方法を決定できます。

GitLab CIとGitLabリポジトリプラットフォームの密接な結合は、ソフトウェアの使用方法に明確な影響を与えます。 GitLab CIは、他のリポジトリホスティングプラットフォームを使用する開発者向けのオプションではありません。 プラス面として、統合された機能により、GitLabユーザーは追加のツールをインストールして学習しなくてもCI / CD環境をセットアップできます。 自動テストを開始するには、Webインターフェイスでいくつかのオプションを有効にし、ランナーマシンを登録し、パイプライン定義ファイルをリポジトリに追加します。 また、緊密な関係により、プロジェクト間でランナーを共有し、リポジトリ内の現在のビルドステータスを自動的に確認し、ビルドアーティファクトを生成したコードで保持することができます。

GitLabおよびGitLab CIはRubyおよびGoで記述され、MITライセンスの下でリリースされます。 how to GitLab CIで継続的統合パイプラインを設定するを使用して、GitLabサーバーでこの機能を構成する方法を学習します。

Buildbot

Buildbotは、途方もない量の柔軟性を提供する継続的な統合フレームワークです。 MozillaのTinderboxプロジェクトの代替として2003年に最初にリリースされたBuildbotは、主に幅広いプラットフォームでビルドテストを自動化する方法として設計されました。

BuildbotはGPLライセンスでリリースされ、Twistedライブラリを使用してPythonで記述されています。 構成を簡素化するために基礎となる言語を抽象化するのではなく、Buildbotの構成はすべてPythonで記述されています。 つまり、構成は他のシステムよりもはるかに複雑になる傾向がありますが、管理者には理想的なワークフローとプロセスを設計する余地があります。 ビルドの各段階は明確に分離され、プログラム可能です。 Buildbotは、独自のカスタムプロセスを構築するツールを備えたフレームワークとしての地位を確立しています。これは、Webフレームワークを使用してカスタムサイトを構築する方法に匹敵します。

Buildbotのビルドテストプラットフォームとしての歴史は、さまざまなオペレーティングシステムとバージョン管理システムをサポートしていることを意味します。 同様に、オープンソーステストを念頭に置いて設計されているため、そのアーキテクチャにより、ユーザーは好みのプラットフォームを持つワーカーをプロジェクトに簡単に送信して、利用可能なテストベースを拡張できます。 ユーザーは、システムにいくつかのPythonパッケージをインストールし、プロジェクトに資格情報を提供するだけです。

Buildbotを使用してビルドプロセスを自動化するには、https://www.digitalocean.com/community/tutorials/how-to-install-buildbot-on-ubuntu-16-04 [UbuntuにBuildbotをインストールする方法]のガイドに従ってください。 16.04]。

ドローン

Droneは、コンテナファーストアーキテクチャで構築された最新のCI / CDプラットフォームです。 上記のツールにはすべてDockerでビルドを実行するオプションが含まれていますが、コンテナベースのワークフローはDroneの設計の中核です。 DroneはGoで記述され、2014年にApacheライセンスの下で最初にリリースされました。

ドローンは、Dockerとリポジトリプロバイダーの間の中間調整層として機能します。 CI / CDサーバーを起動してからバージョン管理システムホスティングサービスに接続するのではなく、Droneは独自の認証、ユーザー、および権限モデルをブートストラップするために、事前にリポジトリアカウント情報を必要とします。 すべてのCIプロセスと同様に、Drone自体はコンテナーとして実行されます。 複数のデータベースバックエンドとリポジトリプロバイダーをサポートし、トランスポート暗号化のためにhttps://letsencrypt.org/[Let’s Encrypt]でTLS / SSL証明書をセットアップするための組み込みサポートを備えています。

ドローンは、パイプライン定義のリポジトリ内で特別なYAMLファイルを探します。 構文は読みやすく表現力豊かに設計されているため、リポジトリを使用する人は誰でも継続的な統合プロセスを理解できます。 Droneはプラグインシステムを提供しますが、Jenkinsのものとは異なる方法で使用されます。 Droneでは、プラグインは事前設定されたタスクを通常のワークフローにドロップするために使用される特別なDockerコンテナです。 これにより、プロセス全体を手動でスクリプト化するのではなく、いくつかのパラメーターを指定してプラグインを呼び出すことで、一般的なタスクを簡単に実行できます。 この意味で、Droneプラグインは、1つの狭い焦点のタスクをうまく実行するように設計されたUnixユーティリティコマンドにいくらか似ています。

コミットを自動的にテストするようにドローンサーバーをセットアップする方法については、https://www.digitalocean.com/community/tutorials/how-to-install-and-configure-drone-on-ubuntu-16-04に従ってください。 [Ubuntu 16.04でのDroneのインストールおよび設定方法]ガイド。

コンコース

Concourseは、2014年に最初にリリースされた比較的新しい継続的統合プラットフォームです。 ConcourseのCI / CD空間へのアプローチは、可能な限り方程式から抜け出そうとし、状態を最小化し、すべての外部要因を「リソース」と呼ぶものに抽象化するという点で、他のツールとは大きく異なります。 この哲学の目的は、統合サーバーを完全に使い捨てにして、同じプロセスを任意のConcourseサーバーで簡単に実行できるようにすることです。

継続的な統合プロセスのすべての部分は、システムのさまざまな要素をモデル化する基本的なプリミティブから構成されます。 プロセスの各部分は、依存関係を明示的に定義します。 たとえば、最初のタスクではVCSリポジトリへの最新のコミットが必要になる場合がありますが、プロセスの後半では、以前のステージを通過した最新のコミットが必要になる場合があります。 各ステップの正確な依存関係をマッピングしてパイプラインを構築するこの方法は、厳密に定義された動作につながります。

プロセスから偶発的な状態をさらに削除するために、Concourseは暗黙的にジョブ間で何かをやり取りせず、ビルドアーティファクトを格納する内部的な方法を提供しません。 次の段階で必要なすべての情報を明示的に定義し、潜在的に外部ストアにプッシュして次のステップにプルする必要があります。 明示的な定義を要求することにより、Concourseはシステムが考慮しなければならない仮定と未知の変数の数を最小限に抑えることを望んでいます。

ConcourseはGoで記述され、Apacheライセンスの下でリリースされます。 Concourseサーバーをセットアップして継続的な統合プロセスを自動化する方法を学びたい場合は、https://www.digitalocean.com/community/tutorials/how-to-install-concourse-ci-onのガイドをご覧ください-ubuntu-16-04 [Ubuntu 16.04にConcourse CIをインストールする方法]。

結論

継続的な統合、配信、展開ソフトウェアは、プロセスを信頼性と再現性のあるものにするために設計された複雑な自動化システムです。 上記の説明からわかるように、自動化されたテストとリリースがどのように最適に達成されるかについて、方程式のさまざまな部分に重点を置いて、さまざまなアイデアがあります。 すべてのプロジェクトのニーズを満たす単一のツールはありませんが、非常に多くの高品質のオープンソースソリューションが利用できるため、チームのニーズを満たすシステムを見つけることができる可能性が高くなります。

前の投稿:Ubuntu 14.04でRancherおよびDockerマシンを使用してマルチノード展開を管理する方法
次の投稿:Debian 10にNginxをインストールする方法