GitLab CI対ジェンキンス

Jenkinsと、Gitディストリビューションに同梱されているGitLab CI drone.ioのような他のCIとの違いは何ですか。いくつかの研究で私はGitLabコミュニティ版はJenkinsが追加されることを許さないがGitLabエンタープライズ版はそうすることができるということを思いつくことしかできなかった。他に大きな違いはありますか？

gitjenkinsgitlabgitlab-cidrone.io

104

2016/05/25Ravikiran763

これが私の経験です。

私の仕事ではGitLab EEを使ってリポジトリを管理し、Jenkinsサーバー（1.6）を稼働させています。

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

TL; DR;

Jenkinsの方が使いやすいですが、プラグインの地獄になる危険性があります。
JenkinsにはGUIがあります（他の人がアクセス可能/保守可能にする必要がある場合はこれが推奨されます）。
GitLabとの統合はGitLab CIよりも少ない
Jenkinsはあなたのリポジトリから切り離すことができます

ほとんどのCIサーバーはかなり単純です（ concourse.ci ）、 gitlab-ci 、 circle-ci 、 travis-ci 、 drone.io 、 gocd 、その他何がありますか？）それらはあなたがYAMLファイル定義からShell/batスクリプトを実行することを可能にします。 Jenkinsはもっとプラグイン可能で、UIが付属しています。これは、ニーズに応じて、利点と欠点のどちらかになります。

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

私の意見では、Jenkinsでのジョブの連鎖と編成は、（UIのために）YAML（curlコマンドの呼び出し）よりもずっと簡単です。それに加えて、Jenkinsは特定のバイナリがあなたのサーバーで利用できないときにインストールするプラグインをサポートしています（他の人にとってはそれについては知りません）。

最近では（ Jenkins 2 はJenkinsfileおよび pipline Jenkins 2からデフォルトで提供される==プラグインを使用して、より適切なciをサポートしています）。すなわちGitLab CIより。

YAMLファイルを使用してビルドパイプラインを定義すること（そして最終的には純粋なShell/batを実行すること）はよりクリーンです。

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

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

彼らのドキュメンテーションはあなたをすぐに始めさせるでしょう。
始めるためのしきい値は非常に低いです。
メンテナンスは簡単です（プラグインなし）。
ランナーのスケーリングは簡単です。
CIはリポジトリの一部です。
ジェンキンスの仕事/意見は面倒になることがあります。

執筆時点でいくつかの特典：

単一のファイルのみをサポートしますが、近いうちに fixed になる予定です。

105

2016/05/25Rik

私はRikのノートの大部分に同意するが、どちらがより単純であるかについての私の意見は反対である。

大部分の力は、自己完結型であり、同じブラウザ内の同じ製品にすべてのを統合していることに由来します。タブ：リポジトリブラウザから、掲示板を発行するか、履歴を構築ツールに展開し、モニタリング。

私は今、さまざまなLinuxディストリビューションにアプリケーションがどのようにインストールされるかを自動化してテストするためにそれを使っています。それは設定が非常に速い（ Firefoxで複雑なJenkinsのジョブ設定を行い、応答しないスクリプトが表示されるのを待ちます（.gitlab-ci.ymlを編集するのは軽量です）。

ランナーバイナリのおかげで、スレーブの設定やスケーリングに費やされる時間はかなり少なくなります。加えて、 GitLab.com ではあなたはかなりまともで無料の共有ランナーを手に入れることができます。

Jenkinsは、数週間後にGitLab CIのパワーユーザーになったあと、より手動になったと感じています。ブランチごとにジョブを複製し、SCPアップロードなどの簡単なことをするためのプラグインをインストールする。今日のように私がそれを見逃したところが直面した唯一のユースケースは、複数のリポジトリが関係している場合です。それはまだうまく理解されている必要があります。

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

2017/03/08Alfageme

まず第一に、今日の時点で、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つのコンポーネント間のダイアログインターフェイスを（おそらくひどく）再開発するよりも常に良い方法です。

コードとしてのパイプラインもgroovyscriptsを使って利用できます。

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

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

GitLab CIが（チェーン、ラン、モニターなど）パイプラインを編成し、GitLabに統合されたそのグラフィカルインターフェースを利用することができます。
Jenkinsは仕事をこなし、サードパーティ製のツールとの対話を容易にします。

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

cI/CDプロセス全体を作り直すことなく、ビルドファクトリコンポーネントを置き換えることができます。
jenkins、TeamCityを組み合わせた（場合によっては複数の）異種のビルド環境があるかもしれませんが、それでも単一の監視ツールを使用することができます。

トレードオフ

もちろん、この設計には代償を払う必要があります。初期設定は面倒であり、多くのツールについて最低限の理解を深める必要があります。

このため、このような設定はお勧めしません。

あなたが扱うべき多くの第三者ツールを持っています。 Jenkinsが多くのプラグインを使って非常に便利になるのはそのときです。
それぞれが異なるビルド環境を持ち、異種のテクノロジを持つ複雑なアプリケーションを扱う必要がありますが、それでも統一されたアプリケーションライフサイクル管理UIを持つ必要があります。

あなたがこれらの状況のどちらにもいないならば、あなたはたぶん2つのうちの1つだけで、両方ではないほうがよいです。

私が選ばなければならなかった場合

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

回答1

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

回答2

あなたがすべてCI技術の新入生であるならば、ただ1つを選んで、行ってください。

GitLabを使用していて、コードとしてすべてのことにコツがある場合は、GitLab CIを選択することをお勧めします。
あなたが他の多くのCI/CDツールと対話しなければならないか、絶対にあなたの仕事を構築するためにそのGUIを必要とするならば、Jenkinsに行きなさい。

GitLabを使用していて、今後もそうするかどうかわからない場合は、GitLab CIを選択したことですべてのCI/CDパイプラインがゴミ箱に捨てられることを意味します。

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

2018/10/17avi.elkharrat

GitLab CIを使った最近の実験から、いくつかの発見を加えたいと思います。 11.6と11.7に付属の機能はただ素晴らしいです！

特に私は基本的にあなたがmerge_requestまたはonlyのために別々のパイプラインを構築することを可能にする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/01/29Stepan Vrany