前書き
Continuous integration, delivery, and deploymentは、十分にテストされた使用可能な製品の開発とリリースの速度を上げるために設計された戦略です。 継続的な統合により、開発チームは変更を共有コードベースにテストし、早期に統合して、統合の競合を最小限に抑えることができます。 継続的な配信は、展開またはリリースへの道の障壁を取り除くことにより、この基盤から構築されます。 連続展開は、テストスイートに自動的に合格するすべてのビルドを展開することにより、さらに一歩進みます。
上記の用語は主に戦略と実践に関するものですが、ソフトウェアツールは組織がこれらの目標を達成できるようにする上で大きな役割を果たします。 CI/CD software can help teams advance new changes through a series of stages automatically to reduce the time to feedback and remove friction from the process.
このガイドでは、共同ソフトウェア開発を容易にするために設計された、人気のある無料およびオープンソースの継続的統合、配信、展開サーバーを比較します。 Jenkins、GitLab CI、Buildbot、Drone、およびConcourseを見ていきます。
ジェンキンス
Jenkinsは、最も初期のオープンソースの継続的インテグレーションサーバーの1つであり、現在でも最も一般的に使用されているオプションです。 元々はHudsonプロジェクトの一部でしたが、元の開発者であるSun Microsystemsを買収した後、Oracleとの商標の競合に続いて、コミュニティとコードベースが分割されました。 ハドソンは当初2005年にリリースされましたが、ジェンキンスとしての最初のリリースは2011年に行われました。
長年にわたり、ジェンキンスはソフトウェア関連のタスクを自動化する強力で柔軟なシステムに進化してきました。 Jenkins自体は、プラグインのライブラリを介して実装される重要なロジックの多くを備えた自動化フレームワークとして主に機能します。 Webフックのリッスンやリポジトリの監視から環境の構築、言語サポートまで、すべてがプラグインによって処理されます。 これによりかなりの柔軟性が得られますが、CIプロセスは多数のサードパーティプラグインに依存するようになる可能性があります。
Jenkinsのパイプラインワークフローは、プラグインを通じても提供されますが、2016年から利用できる比較的新しい追加機能です。 CIプロセスは、リポジトリ自体内のファイル内のGroovy languageを使用して、またはJenkins Web UIのテキストボックスを介して、宣言的または命令的に定義できます。 Jenkinsの一般的な批判の1つは、プラグイン中心の構成モデルと、リポジトリの外部でパイプラインを定義したりプロセスを構築したりする機能により、別のJenkinsインスタンスで構成を簡単に複製することが困難になる場合があることです。
JenkinsはJavaで記述され、MITライセンスの下でリリースされています。 how to install Jenkins on Ubuntu 16.04に関するガイドに従って、プロジェクトのJenkinsサーバーを構成します。
GitLab CI
GitLab CIは、gitリポジトリホスティングおよび開発ツールプラットフォームである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 set up continuous integration pipelines with GitLab CIに関するガイドに従って、GitLabサーバーでこの機能を構成する方法を学ぶことができます。
Buildbot
Buildbotは継続的インテグレーションのフレームワークであり、非常に高い柔軟性を提供します。 MozillaのTinderboxプロジェクトの代替として2003年に最初にリリースされたBuildbotは、主に幅広いプラットフォームでビルドテストを自動化する方法として設計されました。
BuildbotはGPLライセンスでリリースされ、Twistedライブラリを使用してPythonで記述されています。 構成を簡素化するために基礎となる言語を抽象化するのではなく、Buildbotの構成は完全にPythonで記述されています。 つまり、構成は他のシステムよりもはるかに複雑になる傾向がありますが、管理者には理想的なワークフローとプロセスを設計する余地があります。 ビルドの各段階は明確に分離され、プログラム可能です。 Buildbotは、独自のカスタムプロセスを構築するツールを備えたフレームワークとしての地位を確立しています。これは、Webフレームワークを使用してカスタムサイトを構築する方法に匹敵します。
Buildbotのビルドテストプラットフォームとしての歴史は、さまざまなオペレーティングシステムとバージョン管理システムをサポートしていることを意味します。 同様に、オープンソーステストを念頭に置いて設計されているため、そのアーキテクチャにより、ユーザーは好みのプラットフォームを持つワーカーをプロジェクトに簡単に送信して、利用可能なテストベースを拡張できます。 ユーザーは、システムにいくつかのPythonパッケージをインストールし、プロジェクトに資格情報を提供するだけです。
Buildbotを使用してビルドプロセスを自動化するには、how to install Buildbot on Ubuntu 16.04に関するガイドに従ってください。
ドローン
Droneは、コンテナーファーストアーキテクチャで構築された最新のCI / CDプラットフォームです。 上記のツールにはすべてDockerでビルドを実行するオプションが含まれていますが、コンテナベースのワークフローはDroneの設計の中核です。 DroneはGoで記述され、2014年にApacheライセンスの下で最初にリリースされました。
ドローンは、Dockerとリポジトリプロバイダーの間の中間調整層として機能します。 CI / CDサーバーを起動してからバージョン管理システムホスティングサービスに接続するのではなく、Droneは独自の認証、ユーザー、および権限モデルをブートストラップするために、事前にリポジトリアカウント情報を必要とします。 すべてのCIプロセスと同様に、Drone自体はコンテナーとして実行されます。 複数のデータベースバックエンドとリポジトリプロバイダーをサポートし、トランスポート暗号化用にLet’s Encryptを使用してTLS / SSL証明書を設定するためのサポートが組み込まれています。
ドローンは、パイプライン定義のリポジトリ内で特別なYAMLファイルを探します。 構文は読みやすく表現力豊かに設計されているため、リポジトリを使用する人は誰でも継続的な統合プロセスを理解できます。 Droneはプラグインシステムを提供しますが、Jenkinsのものとは異なる方法で使用されます。 Droneでは、プラグインは事前設定されたタスクを通常のワークフローにドロップするために使用される特別なDockerコンテナです。 これにより、プロセス全体を手動でスクリプト化するのではなく、いくつかのパラメーターを指定してプラグインを呼び出すことで、一般的なタスクを簡単に実行できます。 この意味で、Droneプラグインは、1つの狭い焦点のタスクをうまく実行するように設計されたUnixユーティリティコマンドにやや似ています。
コミットを自動的にテストするようにドローンサーバーを設定する方法については、how to install and configure Drone on Ubuntu 16.04ガイドに従ってください。
コンコース
Concourseは、2014年に最初にリリースされた比較的新しい継続的インテグレーションプラットフォームです。 ConcourseのCI / CD空間へのアプローチは、可能な限り方程式から抜け出そうとし、状態を最小化し、すべての外部要因を「リソース」と呼ぶものに抽象化するという点で、他のツールとは大きく異なります。 この哲学の目的は、統合サーバーを完全に使い捨てにして、同じプロセスを任意のConcourseサーバーで簡単に実行できるようにすることです。
継続的統合プロセスのすべての部分は、システムのさまざまな要素をモデル化する基本的なプリミティブから構成されます。 プロセスの各部分は、依存関係を明示的に定義します。 たとえば、最初のタスクではVCSリポジトリへの最新のコミットが必要な場合がありますが、プロセスの後半では最新のコミットthat passed previous stagesが必要になる場合があります。 各ステップの正確な依存関係をマッピングしてパイプラインを構築するこの方法は、厳密に定義された動作につながります。
プロセスから偶発的な状態をさらに削除するために、Concourseは暗黙的にジョブ間で何かをやり取りせず、ビルドアーティファクトを格納する内部的な方法を提供しません。 次の段階で必要なすべての情報を明示的に定義し、潜在的に外部ストアにプッシュして次のステップにプルする必要があります。 明示的な定義を要求することにより、Concourseはシステムが考慮しなければならない仮定と未知の変数の数を最小限に抑えることを望んでいます。
ConcourseはGoで記述され、Apacheライセンスの下でリリースされます。 継続的インテグレーションプロセスを自動化するためにConcourseサーバーをセットアップする方法を学びたい場合は、how to install Concourse CI on Ubuntu 16.04に関するガイドを確認してください。
結論
継続的な統合、配信、展開ソフトウェアは、プロセスを信頼性と再現性のあるものにするために設計された複雑な自動化システムです。 上記の説明から収集できるように、自動化されたテストとリリースがどのように最適に達成されるかについて、さまざまなアイデアがあり、方程式のさまざまな部分に重点が置かれています。 すべてのプロジェクトのニーズを満たす単一のツールはありませんが、非常に多くの高品質のオープンソースソリューションが利用できるため、チームのニーズを満たすシステムを見つけることができる可能性が高くなります。