[解決済み] GitLab CIとJenkinsの比較【終了しました

質問

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

どのように解決するのですか？

これは私の経験です。

私の職場では、GitLab EEでリポジトリを管理し、Jenkinsサーバー(1.6)が稼働しています。

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

TL;DR。

• Jenkinsは使いやすい・覚えやすいが、プラグイン地獄になる危険性がある
• JenkinsはGUIを持つ（他の人がアクセス/メンテナンス可能である必要がある場合、これは好ましいことである）。
• GitLabとの統合はGitLab CIより少ない
• Jenkinsはリポジトリから分離することができる

ほとんどのCIサーバは、非常にわかりやすい( concourse.ci ), gitlab-ci , circle-ci , トラビス-CI , drone.io , gocd など)。これらは、YAMLファイルの定義からシェル/batスクリプトを実行することができます。Jenkinsはよりプラグイン化しやすく、UIが付属しています。これは、あなたのニーズによって、利点にも欠点にもなりえます。

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

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

現在では ( Jenkins 2 は、より多くの "適切な ci" をサポートするようになりました。 Jenkinsfile と パイプライン プラグインがありますが、GitLab CIよりもリポジトリとの連係が弱いです。

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

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

最近、私はGitLab CIで仕事をすることが多くなってきました。GitLabでは、彼らは経験全体を楽しくするために本当に素晴らしい仕事をしています。Jenkinsを使う人がいることは理解していますが、GitLabが動いていて利用可能であれば、GitLab CIを始めるのは本当に簡単です。サードパーティとの連携にも力を入れていますが、GitLab CIほどシームレスに統合できるものはないでしょう。

• 彼らのドキュメントを見れば、すぐに始められるはずだ。
• 始めるための敷居が非常に低い。
• メンテナンスが簡単（プラグインなし）。
• ランナーのスケーリングが簡単です。
• CI は完全にあなたのリポジトリの一部です。
• Jenkins のジョブ/ビューは厄介になることがあります。

執筆時点の特典もあります。

• コミュニティ版では 1 つのファイルのみをサポートします。マルチプル ファイルを エンタープライズ版 .