Jenkins

1. 表示中のページ:
2. GitLabと他のDevOpsツールの比較
3. Jenkins

このページのコンテンツ

• 概要
• 要約
• 不足部分
• コメント/逸話
• 戦略
• リソース
• 料金
• 気になる質問
• 比較

概要

Plugins

Plugins

DevOptics

Plugins

DevOptics

On Roadmap

On Roadmap

On Roadmap

DevOptics

On Roadmap

Plugins

On Roadmap

Plugins

On Roadmap

Plugins

On Roadmap

Plugins

On Roadmap

Integration with ServiceNow

Plugins

On Roadmap

Plugins

On Roadmap

Plugins

Plugins

Plugins

Plugins

Plugins

Plugins

On Roadmap

Plugins

On Roadmap

Plugins

Plugins

Plugins

Plugins

Via Integration

Plugins

Plugins

Via Integration

On Roadmap

Plugins

Plugins

Via Integration

On Roadmap

Plugins

Plugins

Via Integration

On Roadmap

Plugins

Plugins

Via Integration

Plugins

Via Integration

Plugins

Via Integration

Plugins

On Roadmap

Jenkins X

Plugins

Plugins

Plugins

Plugins

Plugins

Plugins

Plugins

Plugins

Plugins

Plugins

Plugins

Plugins

Plugins

Plugins

Plugins

On Roadmap

On Roadmap

Via Integration

Plugins

Via Integration

Plugins

Plugins

Jenkins X

Plugins

Via Jenkins X

Plugins

CodeShip

Plugins

Jenkins X

Jenkins X

Jenkins X

Plugins

Via Plugins

Plugins

Plugins

Jenkins X + Plugins

Plugins

On Roadmap

Plugins

On Roadmap

Plugins

On Roadmap

Plugins

Plugins

Plugins

Plugins

Jenkins X

Plugins

Plugins

Plugins

Via Integration

On Roadmap

Plugins

Via Integration

On Roadmap

Plugins

On Roadmap

On Roadmap

On Roadmap

On Roadmap

On Roadmap

On Roadmap

On Roadmap

要約

Jenkinsは世界中でもっとも人気のあるビルドの自動化、およびCI/CDツールの一つです。何百もの利用可能なプラグインの機能を組み込むことで、信じられないほどの柔軟性が生まれ、あらゆるプロジェクトの構築、デプロイ、自動化をサポートすることができます。

2018年第3四半期のJenkins Worldカンファレンスでは、CloudBees（Jenkinsの主要メンテナー）がJenkinsを分割してクラウドネイティブ版と、簡易化された機能制限版（Jenkins Evergreen）に注力することで、Jenkinsの競争力を復活させる意向を発表しています。また、Jenkins XというJenkinsのサブプロジェクトもあり、Kubernetesを使ったパイプラインの実行を容易にすることを目的としています。

Jenkins Xは、Jenkins CI/CDサーバ、Kubernetes、Helmなどのツールをネイティブに統合し、GitOpsを使って環境を管理するなど、ベストプラクティスを組み込んだ模範的なCI/CDパイプラインを提供します。KubernetesコンテナへJenkinsをデプロイすることで、Jenkinsのインストールと統合の複雑さを回避します。しかし、Jenkinsサーバをはじめ、多くのツールが複雑に組み合わされているため、メンテナンスは容易ではありません。

対照的に、GitLabはすでに、DevOpsのライフサイクル全体に完全に統合されたオールインワンのアプリケーションを提供することで、Jenkinsが期待している以上のものを提供しています。Jenkinsが注力しているCI/CDに加えて、GitLabは計画、ソースコード管理、パッケージング、リリース、構成、モニタリングの機能も提供しています。

不足部分

• Jenkinsのネイティブ機能の拡張はプラグインを使って行います。プラグインの維持・セキュリティ・アップグレードにはコストがかかります。対照的に、GitLabはオープンコアであり、誰もが直接コードベースに変更を投稿することができ、一度マージされれば変更のたびに自動的にテストされ、メンテナンスされます。

コメント/逸話

• HackerNewsのスレッド - Jenkins is Getting Old。
• Jenkinstein - 記事よりDevOps World 2018: ‘Jenkinstein’ and a Cloud Native Jenkins。
  • Snowflake サーバと "Brent" の状況と、それがどのようにすべてを遅くするかを説明します。これは、Jenkinsユーザーが今日直面している主要な問題の1つであり、Jenkinsには簡単な解決策がありません。

    このチャネルのゲートキーパーとして機能しているのは、CloudBeesのCEOであるSacha Labourey氏が「Jenkinsガイ…彼のチームでJenkinsを素晴らしいものにすることに専念しているスーパースター」と表現した人物である。この人物は彼の組織内でのデプロイの権威であるため、複数のチームがスケジューリングの目標を達成するために彼を頼りにしています。しかし、これが技術的な問題につながり、IT運用以外ではほとんどの人が時間をかけて検討することができません。複数のエージェントで分散スキームを管理するサーバーは、古い電話帳やWindows XPのシステムレジストリのように肥大化してしまいます。

    そして、その組織のJenkinsのデプロイはJenkinsガイに依存しているだけでなく、プラグインの選択に多少縛られているため、その結果、CEOが "フランケンシュタインJenkins "と呼んだものや、火曜日のカンファレンスで他の開発者やエンジニアが "Jenkinstein "と呼んでいたものになってしまいます。

  • 再び、CloudBees CEOのSacha Labourey氏が、現在のJenkinsに共通する問題点を説明しています:

    Jenkinsは肥大化し、起動に時間がかかります。クラッシュすると、起動に時間がかかります。何百人もの開発者が怒っています。そして誰もそれを修正しようとしません。

• CloudBees CTOでありJenkinsの作者の川口耕介氏の2018年8月31日のメモより(https://jenkins.io/blog/2018/08/31/shifting-gears/):
  • "Our Challenges. . . Service instability. . . Brittle configuration. . . Assembly required. . . Reduced development velocity. . ." (see above link for details on each)
  • "Path forward. . . Cloud Native Jenkins. . . continue the incremental evolution of Jenkins 2, but in an accelerated speed"
  • 重要なポイント:
    • 彼らは今後のリリースで後方互換性を壊す予定です
    • クラウドネイティブなJenkinsのために新しい仕組みの導入を計画しています
    • 今日からJenkinsを使う人は、大きな変更に注意したほうが良さそうです
• Jenkins Evergreenプロジェクトのページから(上の耕介氏の手紙の中で、来るべき変更のための鍵として認識されています) - https://github.com/jenkinsci/jep/blob/master/jep/300/README.adoc
  • "Pillars . . . Automatically Updated Distribution . . . Automatic Sane Defaults. . . Connected. . . Obvious Path to User Success"
  • "The "bucket of legos" approach is . . . not productive or useful for end-users [5] who are weighing their options between running Jenkins, or using a CI-as-a-Service offering such as Travis CI or Circle CI."
  • "existing processes around "Suggested Plugins", or any others for that matter, result in many "fiefdoms" of development rather than a shared understanding of problems and solutions which should be addressed to make new, and existing, users successful with Jenkins."
• Jenkins Evergreenプロジェクトページの「問題」定義ページより (https://github.com/jenkinsci/jep/blob/master/jep/300/README.adoc#problem):

  初心者から中級者のユーザにとって，Jenkins環境を「ゼロから」一般的な CI/CDワークロードの生産性の高いものに準備するのに必要な時間は，Jenkinsとそれに関連する技術の理解度にもよるが，数時間から数日に及ぶことがある。また、環境の準備は非常にエラーが発生しやすく、最新の状態、安全性、生産性を維持し続けるためには、継続的なメンテナンスのオーバーヘッドが必要になることもある。

  さらに、多くのJenkinsユーザーは、プロジェクトに適したCI/CD環境を構築するために、どのプラグインをどのように組み合わせ、どのような方法で、どのように設定すべきかを決定することになると、選択のパラドックス[6]に悩まされます。これはJEP-2 [7]がJenkins 2.0で導入された "セットアップウィザード "で解決しようとした問題に関連しているが、Jenkins Evergreenは、ユーザーがJenkinsのメンテナンスよりも、プロジェクトの構築、テスト、提供に集中できるように、（既存のプラグインのセットによって提供される）共通機能の低オーバーヘッドでメンテナンスが容易な、強固なディストリビューションをユーザーに提供するというより広い問題に対処することを目的としている。

• 新しいJenkinsの改善の取り組みについてのフィードバックに関するGitLabブログ - https://about.gitlab.com/blog/2018/09/03/how-gitlab-ci-compares-with-the-three-variants-of-jenkins/
• CloudBeesのドキュメントで変更の必要性を証明するものとして指摘されたJenkinsのプロジェクト分析 - https://ghc.haskell.org/trac/ghc/wiki/ContinuousIntegration#Jenkins

  長所

  • 我々は、我々が設定する任意のアーキテクチャとOS上でビルドノードを実行することができます。

  短所

  • PRビルドでは、ビルドを適切にサンドボックス化するためにさらに労力をかけない限り、セキュリティは低いです。また、サンドボックス化してもJenkinsのセキュリティレコードは厄介です。
  • Jenkinsは設定に時間がかかることで知られています。
  • サーバーの設定にはより多くの時間がかかります。
  • サーバーのメンテナンスにはより多くの時間がかかります。
  • 再現性のある設定がどれだけ簡単にできるかは不明です。
  • セットアップはフォークできません（フォーカーは自分のサーバーをセットアップする必要があります）。

• GitLabのPMMより

  • "JenkinsはKubernetesと連携するために、まったく別のプロジェクトを構築しなければなりませんでした。GitLabは最初からKubernetesをネイティブに採用しています。"
  • Jenkins Xの採用はごくわずかです。Kubernetesに移行しようとしている人のほとんどはJenkinsを使っているでしょうから、Pinterestの例が当てはまります。
  • Jenkins XはKubernetesで動作しますが、GitLabのような単一のアプリケーションではありません。 PPM、SCM、セキュリティツールなどとインテグレーションする必要があります。

戦略

Jenkins objection handling (GitLab access only) Jenkins objection handling Q&A (GitLab access only)

リソース

• Jenkins OSS ウェブサイト - Open Source project website
• CloudBees Jenkins ウェブサイト - https://www.cloudbees.com/products/cloudbees-core
• Jenkins X ウェブサイト

料金

• Jenkins OSS
  • 無料 (かつオープンソース)
  • しかし、メンテナンスの必要性を考えると、総所有コストはゼロではありません。
• CloudBees Jenkins (不明瞭) - https://www.cloudbees.com/products/pricing
  • CloudBees Core - 毎月の増分アップグレード、クラウドネイティブアーキテクチャ、集中管理、24時間365日のサポートとトレーニング、エンタープライズグレードのセキュリティとマルチテナンシー、プラグインの互換性テストなどのアップグレード支援付きのJenkinsディストリビューション
    • 10ユーザーで年間20,000ドルから、大規模な組織ではユーザーごとのコストを低く抑えるための段階的な価格設定が可能
• Jenkins X
  • 無料 (かつオープンソース)
  • しかし、総所有コストはかかります（Pinterestの逸話参照)

気になる質問

• "Jenkinsで必要な機能を利用するためにJenkinsのプラグインを使っていますか？プラグインの数は？"
  • 平均すると7〜9という回答が期待されます。
  • 続く: "私たちが話を聞いている組織のほとんどは、Jenkinsプラグインの管理は悪夢だと言っています。それぞれのプラグインには独自の開発ライフサイクルがあり、新しいプラグインが必要になるたびにツールチェーン全体を再テストしなければなりません。グループAがプラグインAを必要としていて、Jenkins管理者がそれをインストールしたところ、プラグインBが必要とするライブラリの新しいバージョン（互換性のない）に依存していることが判明し、グループBが必要としていることがわかった、というような話を聞いたことがあります。解決策は？ 各グループにそれぞれ独自のJenkinsサーバを与えてはどうでしょう？しかし、その場合は、Jenkinsのスプロール(管理するサーバの数が増える)が発生してしまいます。ツールチェーン内のすべての外部統合ツールに必要なメンテナンスやテストは言うまでもありません。" (きっとたくさんの人が心当たりのあることだと思います)

比較