GitLab CI対Jenkins [終了]

JenkinsとGitLab CIのような他のCI、Gitディストリビューションに付属しているdrone.ioの違いは何ですか？いくつかの調査では、GitLabコミュニティエディションではJenkinsを追加できないが、GitLabエンタープライズエディションでは追加できると思いました。他に大きな違いはありますか？

これは私の経験です：

私の仕事では、GitLab EEでリポジトリを管理し、Jenkinsサーバー（1.6）を実行しています。

基本的にはほとんど同じです。サーバー/ Dockerイメージでいくつかのスクリプトを実行します。

TL; DR;

• Jenkinsは使いやすく、学習も簡単ですが、プラグインの地獄になる危険があります。
• JenkinsにはGUIがあります（他の人がアクセス/保守できるようにする必要がある場合は、これをお勧めします）
• GitLabとの統合はGitLab CIとの統合よりも少ない
• Jenkinsはリポジトリから分割できます

ほとんどのCIサーバはかなりまっすぐ進む（あるconcourse.ci）、gitlab-CI、円-CI、トラビス-CI、drone.io、gocdと他に何あなたが持っています）。YAMLファイル定義からシェル/バットスクリプトを実行できます。Jenkinsははるかにプラグイン可能で、UIが付属しています。これは、ニーズに応じて、長所にも短所にもなります。

利用可能なすべてのプラグインがあるため、Jenkinsは非常に構成可能です。これの欠点は、CIサーバーがプラグインのスパゲッティになる可能性があることです。

私の意見では、Jenkinsでのジョブのチェーンとオーケストレーションは（UIのため）、YAML（curlコマンドを呼び出す）を使用するよりもはるかに簡単です。その上、Jenkinsは、サーバーで利用できない場合に特定のバイナリをインストールするプラグインをサポートしています（他のバイナリについては知らない）。

今日で（ジェンキンス2はまた、より多くのと、「適切なCI」をサポートJenkinsfileしてpiplineのジェンキンス2から、デフォルトが来るプラグイン）が、あまりすなわちGitLab CIよりもリポジトリに結合するために使用されます。

YAMLファイルを使用してビルドパイプラインを定義する（そして最終的には純粋なシェル/バットを実行する）方がクリーンです。

Jenkinsで使用可能なプラグインを使用すると、テスト結果、カバレッジ、その他の静的アナライザーなど、あらゆる種類のレポートを視覚化できます。もちろん、これを行うためのツールをいつでも作成または使用できますが、これはJenkinsにとっては間違いなくプラスです（特に、これらのレポートを高く評価する傾向があるマネージャーにとって）。

最近、GitLab CIを使用することがますます増えています。GitLabで彼らは本当に素晴らしい仕事をしていて、全体の経験を楽しくしています。私は人々がJenkinsを使用していることを理解していますが、GitLabを実行して利用できるようになれば、GitLab CIを使い始めるのは本当に簡単です。サードパーティの統合にはかなりの努力を払っていますが、GitLab CIほどシームレスに統合されるものはありません。

• 彼らのドキュメントがあればすぐに始められます。
• 開始するためのしきい値は非常に低いです。
• メンテナンスは簡単です（プラグインなし）。
• ランナーのスケーリングは簡単です。
• CIは完全にリポジトリの一部です。
• Jenkinsのジョブ/ビューは乱雑になる可能性があります。

執筆時点での特典：

• コミュニティエディションでは1つのファイルのみがサポートされます。Enterprise Editionの複数ファイル。

私はRikのほとんどのメモに同意しますが、どちらがより簡単であるかについての私の意見は反対です。GitLabは、作業するための素晴らしいツールであることが証明されています。

力のほとんどは、自己完結型であり、同じブラウザータブの下で同じ製品のすべてを統合することに由来します：リポジトリブラウザー、発行ボードまたはビルド履歴からデプロイメントツールおよびモニタリングまで。

現在、さまざまなLinuxディストリビューションへのアプリケーションのインストール方法を自動化およびテストするために使用しています。構成するのは非常に高速です（Firefoxで複雑なJenkinsジョブ構成を開き、応答しないスクリプトが表示されるのを待ちますvs 。編集するのがいかに軽量か.gitlab-ci.yml）。

ランナーバイナリのおかげで、スレーブの構成/スケーリングに費やす時間は大幅に短縮されます。さらに、GitLab.comでは、かなりまともな無料の共有ランナーを入手できるという事実。

Jenkinsは、GitLab CIのパワーユーザーになってから数週間後、たとえばブランチごとにジョブを複製したり、プラグインをインストールしてSCPアップロードなどの単純なことを実行したりすると、よりマニュアルになります。今日見落としているのは、複数のリポジトリが関係している場合だけです。それはまだうまく理解する必要があります。

ところで、私は現在GitLab CIでシリーズを書いており、リポジトリCIインフラストラクチャをそれで構成するのがそれほど難しくないことを示しています。先週公開された最初の作品は、基本、長所と短所、および他のツールとの違いを紹介しています：GitLab CIによる高速で自然な継続的統合

まず、今日の時点で、GitLab Community EditionはJenkinsと完全に相互運用できます。質問なし。

以下では、JenkinsとGitLab CIの両方を組み合わせた成功体験についていくつかフィードバックを提供します。また、両方を使用する必要があるか、どちらか一方のみを使用するか、およびその理由についても説明します。

これがあなた自身のプロジェクトに関する質の高い情報を提供してくれることを願っています

GitLab CIとJenkinsの強み

GitLab CI

GitLab CIは、当然GitLab SCMに統合されています。gitlab-ci.ymlファイルを使用してパイプラインを作成し、グラフィカルインターフェースを介してそれらを操作できます。

コードとしてのこれらのパイプラインは、明らかにコードベースに格納でき、「コードとしてすべて」の手法（アクセス、バージョン管理、再現性、再利用性など）を強制します。

GitLab CIは優れたビジュアル管理ツールです。

• チームのすべてのメンバー（技術以外のメンバーを含む）は、アプリケーションのライフサイクルステータスにすばやく簡単にアクセスできます。
• したがって、リリース管理用のインタラクティブで操作可能なダッシュボードとして使用できます。

ジェンキンス

Jenkinsは優れたビルドツールです。その強みは、多くのプラグインにあります。特に、私はJenkinsと他のCIまたはCDツールとの間のインターフェースプラグインを使用することに大きな成功を収めてきました。これは常に、2つのコンポーネント間のダイアログインターフェイスを再開発する（おそらくひどい）よりも良いオプションです。

コードとしてのパイプラインは、groovyスクリプトを使用して利用することもできます。

GitLab CIとJenkinsを一緒に使用する

最初は少し冗長に聞こえるかもしれませんが、GitLab CIとJenkinsを組み合わせると非常に強力です。

• GitLab CIはパイプラインをオーケストレーション（チェーン、実行、モニター...）し、GitLabに統合されたグラフィカルインターフェイスを活用できます
• Jenkinsはジョブを実行し、サードパーティツールとの対話を容易にします。

この設計のもう1つの利点は、ツール間の疎結合があることです。

• CI / CDプロセス全体をやり直すことなく、ビルドファクトリコンポーネントを置き換えることができます。
• JenkinsとTeamCityを組み合わせた（場合によっては複数の）異機種混合のビルド環境で、名前を付けても、単一の監視ツールを使用できます。

トレードオフ

もちろん、この設計には費用がかかります。最初のセットアップは面倒であり、多くのツールを最小限のレベルで理解する必要があります。

このため、以下の場合を除き、このような設定はお勧めしません。

• あなたが扱うサードパーティのツールがたくさんあります。それは、Jenkinsがその多くのプラグインで非常に便利になるときです。
• 異種のテクノロジーを使用して複雑なアプリケーションを処理する必要があり、それぞれに異なるビルド環境があり、さらに統合されたアプリケーションライフサイクル管理UIが必要です。

これらの状況のどちらにもない場合は、おそらく両方ではなく、どちらか一方だけを使用するほうがよいでしょう。

選ぶ必要がある場合

GitLab CIとJenkinsの両方に長所と短所があります。どちらも強力なツールです。それでどちらを選ぶべきですか？

回答1

チーム（または近い人）がすでにある程度の専門知識を持っているものを選択してください。

回答2

CIテクノロジーの完全な新入生なら、1つ選んで始めましょう。

• GitLabを使用していて、すべてのことをコードとしてこなす場合、GitLab CIを選択することはまったく意味がありません。
• 他の多くのCI / CDツールと対話する必要がある場合、またはジョブを構築するためにそのGUIが絶対に必要な場合は、Jenkinsを使用してください。

GitLabを使用していて、GitLabを使用し続けるかどうかわからない場合は、GitLab CIを選択すると、すべてのCI / CDパイプラインが破棄されることを意味することに注意してください。

最後の言葉です：プラグインが多いため、バランスはJenkinsに少し傾いていますが、GitLab CIがすぐにギャップを埋める可能性があります。

GitLab CIでの最近の実験からの発見をいくつか追加したいと思います。11.6と11.7に付属している機能はすばらしいだけです。

具体的には、only基本的に、merge_requestまたはのパイプラインを個別に構築できる条件が大好きですpush（完全なリストはこちら）

また、私はプラグインがないことを本当に気に入っています。さらに複雑な機能が必要な場合は、必要な機能を処理するカスタムDockerイメージを作成するだけです（これは、drone.ioで確認できる概念と同じです）。

DRYについて不思議に思っているなら、今日では絶対に可能です！「テンプレート」を書くことができます

.myTemplate:
  image: node:10.14.2
  script:
    - npm install
    - npm run test

それらをパブリックリポジトリに配置し、メインパイプラインに含めます。

include:
  - remote: https://....

そして、それらを使用していくつかのジョブを拡張します。

test:
  extends: .myTemplate
  only:
    refs: ["master"]
    variables:
      - $CI_PIPELINE_SOURCE == "push"

GitLab CIが大好きです。ええ、それは（これまでのところ）カバレッジなどで素晴らしいグラフを描くことはできませんが、全体的にそれは本当にすてきなツールです！

編集（2019-02-23）： GitLab CIで好きなものについての私の投稿です。それは11.7「時代」で書かれたので、この答えを読んでいるとき、GitLab CIにはおそらくもっと多くの機能があります。

編集（2019年7月10日）： Gitlab CIは現在、複数のサポートextendsなどを

extends:
 - .pieceA
 - .pieceB

詳細情報を取得するために公式ドキュメントをチェックし、複数の延び

ビルド/パブリッシュ/デプロイおよびテストジョブがそれほど複雑でない場合は、gitlab ciを使用すると自然な利点があります。

gitlab-ci.ymlはすべてのブランチでコードと一緒に存在するため、ci / cdステップ、特にテスト（環境によって異なる）をより効果的に変更できます。

たとえば、devブランチへのチェックインの単体テストを実行したいのに対し、QAブランチで本格的な機能テストを実行し、本番環境で限定的なgetタイプのテストを実行したい場合は、gitlab ciを使用して簡単に実現できます。

優れたUIとは別の2番目の利点は、任意のステージを実行するためにDockerイメージを使用できることです。これにより、ホストランナーがそのまま維持され、エラーが発生しにくくなります。

さらに、gitlab ciは自動的にチェックインし、jenkinsマスターを個別に管理する必要はありません。