アドベントカレンダー最終日、トリを勤めます @legnoh です。
2018年も残りわずかとなりましたがいかがお過ごしでしょうか。
私はもう1記事書こうと思ってたのですが...多忙of多忙につき1記事書くのがやっとでした。
師走だからね、仕方ないね(´・ω・`)
後ギリギリ滑り込みでごめんな(´・ω・`)
前文
私は会社に入るまで、CI/CDという分野に対してはかなり無頓着な人間でした。もともと技術的にPHPがちょっと書ける程度で、チームの開発経験もなく、リリースしたものも自分の個人サイトとGoogleChromeの拡張くらい、という程度の経歴でしたし、最初の頃は随分とやんちゃなコードもたくさん書いていました。しかし曲がりなりにも、１つのリリースを手作業でする度にドキドキしながら黒い画面を開いてコマンドを叩く。自分の作ったものが、サービスという形で世界に放たれていき、アクセスログが一斉に流れる様は、やはり感動を覚えたものです。
そうやって年月を重ね、リリースを幾度となく行い、様々なサービスを担当する経験を積んだ後、思ったことがあったのです。
「ごめん、やっぱリリース作業だるいわ」
そうです、最初のトキメキみたいなものを通りこすと、後はひたすらだるいのです。単調作業、なんとなく通りそうなコードを目視して確認し、他の人にリリース確認をしてもらって、確認しては本番サーバに時間をかけて流す、そんなことを繰り返すうちに、私の心は「俺はリリースマシーンじゃねぇ、サービスを作ることが好きなんだ、サービスが動いてればリリースに時間かけたくない、もっと綺麗なコードと疲弊しないリリースフローが欲しい！端的に言えば楽をしたいんだ楽を！」という気持ちになっていました。
とりあえずやりたいことは「楽をしたい！」しか考えていなかった単純な私は、とりあえず自分がリリースの時に打っていたコードをshellscriptでまとめてドキュメントに置いていましたが、そのうちドキュメントのページに行くのすら億劫になってしまいました。そこで、ボタンポチィだけでリリースしたい。「あ、リリース？わかった(ポチィ)」でドヤ顔したいという虚栄心に塗れた気持ちに溢れていきます。そんな時に、身近にあったのがJenkinsです。単純にShellScriptをcronとかではなく、代理で実行させられる、それだけで大層心が踊ったものです。
そのうち、私はBuild Flow Pluginや、Redmine Plugin をインストールし、ボタンを１つ押すだけでIaaSに開発用のVMを1台立てるようなパイプライン、Redmineのチケットと開発フローの連動、ステージングでテストが終わったものが本番に流れていくパイプラインなどを相当の時間をかけて作り上げ、如何に最速かつ安全なリリースフローを作るか、ということに思いを馳せ、「来週はどのプラグインを試そうかな！」とか、「ここ並列実行にしたらカッコいいんじゃないかな！」とか、そんなことばかりに心を奪われるようになっていきました。何故かサービス開発では全く使わないはずのGroovyが書けるようになり、Redmineと戯れることが増えていき、何故かRubyが書けるようになりました。
そして、ふと振り返って気づいたのです。
いつの間にか、サービス大好きおじさんだった私は、Jenkins(+Redmine)おじさんに進化していたのです。
積み上げたGroovyのパイプラインは、誰もメンテナンスができませんでしたし、他のメンバーはボタンを押すことはできても、そのビルドが失敗した原因を探ることはできない。「傍目に見てる分はすごいし、便利そうなんだけど、よくわからないから触れない」、そんな代物と化していました。
そうやって、ハ●ルの動く城を運用させている時に事件は起きました。異動です。 社命により、私は遠く離れた他の部署への異動を命じられました。「ここまですくすく育ててきたパイプラインたち(とRedmine)を手放せと言うのか！なんて無慈悲な！」と内心思いながら、後ろ髪を引かれつつ、引継ぎ作業を行いました。量にして、Groovyファイル約20枚、Redmineプラグイン約10個。重厚なパイプラインのステップごとの解説手順書つきです。
できるわきゃねぇだろぉ！！！！！！！！！！！！
引き継ぎはリリース作業だけするわけではありません。どちらかと言えばリリース手順はおまけで、本来はサービスの設計だとか、運用にコツがいりそうな部分のケアを中心に行うもので、Jenkinsパイプラインなど、単なるリリースの1手段でしかないわけです。誤解を恐れず言えば、私が作り上げたパイプラインはただの自己満足でしかなく、やろうと思えば手作業でもリリースができてしまうものをまとめただけに過ぎません。パイプラインの構成を理解したりバグを直すより、直接コマンドを打った方が理解しやすいし早い、価値にしてその程度のものでしかなかったわけです。
その後、パイプラインのGroovyスクリプトを入れたリポジトリを見ても、更新履歴が遠い過去に、Jenkinsのジョブ履歴からいつの間にか実行ログも随分と昔の日付だけが並ぶ、そんな物悲しい景色を別の部署から眺めるたび、私はメンテナンス不可能な遺産を残してしまったのではないかと、何度も辛い気持ちになりました。
本題
Jenkins大好きおじさんだった私は、何の因果か、今年1年、全社に展開しているConcourseのプロダクトオーナーを務めていました。おじさんだった当時は、ただの1サービスが野良で立てたJenkinsだったので好き勝手色々なことができましたが、そこそこのエンタープライズな会社で社内展開となれば、話は全く別です。様々なステークホルダの要件を聞き、限られたメンバーのリソースを考慮しながら、そのリクエストに答えた機能を追加したり、内部統制や社内戦略などの要件に従った運用・デプロイフローを作ったりなど、意識することが格段に多くなります。
その中で特に感じるのは、エンタープライズであればあるほど、多種多様なテスト・デプロイに対応しなければならない、という点です。Webサービス1つ取っても、言語は何か、ライブラリマネージャは何か、コンピューティングリソースは？(CF, k8s, Lambda, スマホアプリ)、必要なテストは？(ユニットテストからE2Eまで),リリース手法は(カナリアリリースなど)、求められるセキュリティのレベルは、、、、いくらでも選択肢があり、その掛け合わせを探れば、無数の解が存在します。
そんな中でも、日々成長するエンジニアは、自らの書いたコードを他のメンバーに託し、現場を離れていきます。そのたびに、リリースに使う技術を覚え直さなければならないということは大きなコストになってしまいます。可能な限り、これまで覚えた技術で対応できるなら、リリースのオーバーヘッドは最小にできる。でもそれが覚えられないほど辛いものであったり、他のツールやツールがなくても代替が現実的に効くものであれば、理解するより早く取り替えられ、廃れてしまうことでしょう。
JenkinsやTravisCIが特に多く取り上げられた当時の情勢も様変わりし、多種多様なCI/CDツールが登場し、覇権を争う戦国時代へと突入しました。今年の台風の目となったのはGitHub Actionsだと思われますが、Google Cloud Buildや、今年初頭に発表されたJenkins Xなど、各クラウドベンダーや古参プラットフォームもこの戦乱にまだまだ乗じる気配が漂う昨今、自らの信じるCI/CDパイプラインを選び、作り上げることは、実に大きな意味を持ちます。
そう考えると、この乱世のCI/CDに対して求められるのは、
- 多機能性
- 習得容易性
という2点に収束するのではないかと感じるのです。アジャイルでの開発フロー、DevOpsの文化が様々なジャンルの開発現場に浸透していくにつれ、自らのチームのリリースワークフローを見直す機会は自然と出てくることでしょう。そうなった時、細かくCIツールを使い分けるより、「あれを覚えておけばどう世の中やコマンドが変わろうがすべて対応できる」「いざとなれば自分でコントロールできる」「誰が担当になっても中身がすぐ理解できる」という安心感が、サービスの現場に与えるメリットは、長い目で見ると様々なツールを使い捨てるメリットを遥かに凌駕します。
〆
そうやって取捨選択が繰り返された未来、果たして最適なCI/CDとは何を指すことになるのか、まだまだ分かりません。私の知る限り未だ万能はなく、CI/CDツールの各開発元は自らの弱点を自覚し、様々な修正を繰り返し続けています。そんな時代の中、最適解を選び取るのはやや難しいことと言えるかもしれませんが、心配は不要です。
迷ったら Concourse を選べば良いのです。
様々な要件に沿うパイプラインを自力で組み立てることができ、本体を立てるのも簡単、いざとなればTaskでも頑張れるし、Resourceを作って自由に拡張もできる、シンプルなコンセプトだが奥深く、OSSとして透明性に満ちている。それがConcourseの魅力です。ただ弱点として、最初のハードルがやや高いということ（特に日本語ドキュメントが少ない...）、日本のコミュニティ活動がまだまだ見え辛い点があります。このあたりについては自分も今後やっていきたい思いがあり、CI/CDツールという側面でもっと情報交換ができても良いかな、と感じています。まだまだ先の長い話ではありますが、来年もCI/CDについて、サービスの開発者が楽に、情熱的に開発に没頭できる世界を作りたい。そんな熱い思いを持ちながら、来年もCI/CDやっていこうぜ！ ...ということで、このエントリ、ならびに Concourse Advent Calendar を終わらせて頂こうと思います。
現場の皆様も、年納めの際には監視とメトリクスが効いてるか確認してから、良い年末年始をお過ごしください。
来年もよろしくお願いします！
おまけ
本当はこの内容で22日書こうと思ってたけども
Stark & Wayne 社から出ているConcourseのチュートリアルページ日訳版を作成中です。まだ細かい校正を終えていないまま年を越すことになりそうなので先に晒してしまいますが、もし訳の内容で気になるものがあればご指摘頂けると幸いです