CI/CDがしたいだけのはずなのに、お前はJenkinsが使いたいという

はじめに

この記事はJenkinsを貶める内容では無く、愚痴半分、妄想半分のポエムです。

前提条件

Docker, Kubernetesが業界的に流行ってはいるが、動いているサービスの大半はまだまだVMの上で動いている。

Kubernetesへ絶賛移行中。

一部、温かみのある手作業でリリースを行っているチームもあるが、CI/CDツールとしてはJenkinsが一強で、GitLab等のツールを使っているチームもちらほらある。

DevOps ENGの自分としては、CI/CD Pipelineの統一を行うためにCloud NativeなCI/CDツールを布教していきたい。

なぜ、Jenkinsが使いたいと言うのか？

  • 他のツールの存在は知っているが、Jenkinsで事足りている
  • Jenkins以外のツールを使いたい気持ちはあるが、自分だけが運用者になる事態を避けたい
  • 今までJenkinsを使ってきたので、今更変えたくない
  • Jenkins以外知らないし、知るために投資する余裕はない
  • 意識高い系の人がJenkins以外のツールを中途半端に導入して辞めていったので、Jenkinsに戻した

体感では、結構惰性で使っているケースが多いように感じます。

また、アプリの改修で一ヶ月間の新規開発を止める事は交渉できなくはないと思いますが、CI/CD Pipelineを刷新するから一ヶ月開発を止めさせてくれと言う要望をビジネス側に通すのは至難の技だと思う。

なお、Jenkinsサーバーを運用したくないと言う意見は満場一致だったりします。

なぜ、Jenkinsじゃダメなのか？

  • Javaがインストールされているサーバーがあれば、サクッと動く
  • 多少クセはあるけれど、Jenkins Pipelineを利用すればUIからポチポチJobを設定する手間を省くことができる
  • Pluginが豊富
  • 良くも悪くもネットに情報がたくさんある

このように、Jenkins自体は良くできているんだけれど

  • Masterの設定や、Agentにインストールされるパッケージがカオスになりがち
  • Masterが落ちると何もできなくなる
  • 管理者にしかできない事が多い

とまぁ、リリースサイクルがたかだか数ヶ月に一回程度で、サービスのフェーズとしても運用がメインであれば許容範囲内だけれど、ガンガン変更を加えてガンガンリリースしていきます！ってサービスだと、管理者が忙殺されてボトルネックになりがち。

今までは、言語独自のリリースツールを使っているチームが多く一般化する事は困難であったが、ビルドの成果物はContainerにリリース先はKubernetesに統一された結果CI/CD Pipelineも統一しやすくなった。であれば、特化したツールを活用した方が実装コストや運用コストを減らす事ができるよね。

じゃあ、何なら良いのさ

ここで、ツールの話をするから論点がずれていってしまうんですよ。

Jenkins以外のツールで何が良いか？みたいな観点で議論を始めると、宗教戦争が勃発してしまうので不毛です。

ツールじゃなくてゴールから考えるべきで、正直ゴールはチームの成熟度によって変わってきます。

Atlassianの記事が分かりやすいと思うのですが、ざっくり分けて３段階あります。

  1. 自動テスト・ビルドまでは達成してるけどリリースは手動もしくは半自動で行っている(Continuous Integration)
  2. テスト・ビルドおよび、リリースを自動化している。ただし、リリースはオペレーターがジョブを実行する事で行われる(Continuous Integration & Delivery)
  3. テスト・ビルドを通過したら、自動で本番にリリースされる(Continuous Integration & Deployment)

www.atlassian.com

上記３つの段階にあるチーム全てをカバーできるツールが理想です。

また、ひとつ前の項目で触れたJenkinsの問題点を解決している事が、新たなツールを選定する上での最低条件です。その上で、プラスアルファな利点があってようやく移行するかどうか検討する事ができるようになります。

そして、移行コストを極力０にする事で移行してくれるチームが現れます。

このような現実的な問題がたくさんあるので、安易にArgo CD使おうぜ！とは言いにくい訳です。Continuous Deploymentしたくないチームにとっては全然嬉しくないからね。

ちなみに、Continuous DeliveryとDeploymentの間には技術的な問題だけでなく心理的な問題もあるように思います。

勝手にデプロイして大丈夫？人間がデプロイした方が機微に気付けるのでは？等の心配を解消するために、十分なテストと問題があったらすぐロールバックできる仕組みが必要なのかなと。後者は所謂Progressive Deliveryってやつですね。

今のところ良さげな候補

もちろん、移行しやすいようにPipelineのテンプレは何パターンか用意する必要があるけれども

Tekton Dashboard がSingle Namespaceと認証認可機能をサポートしてくれたら、CIはTekton（手動でリリースしたいチームはリリースにもTekton Pipelineを使ってもらう）、CDはArgo CDで良いのかもしれないと思ってたりしますが、それなんてOpenShift..

もしくは、Tekton Client pluginを使ってJenkinsをDashboardとして使えばいいとこ取りできちゃうかも？