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