先々月に会社でCI/CDをJenkinsから別のものに移行したのですが、Jenkinsには非常にお世話になったので一つ記事を書いておきたいと思いました。

出会い


Jenkinsとの出会いは2014年のちょうど今頃だったと思います。当時私はとある製品の開発・保守の事実上リーダー的ポジションで、ある程度好き勝手やっていました。当時SVNからGitへの移行が完了し、Redmineとの連携も行い、作業は全てチケットで管理されるなど、当時基準で行けばそこそこまともな開発環境が構築されていたのではないかと思います。

余談ですが、当時TFSの導入をプレゼンしたところ「そんな金は出せない」ということで却下を食らった結果、OSSの組み合わせで作り上げたのがこれらの環境でした。当時はかなり腹が立ったのですが、結果的に却下されて良かったのではないかと今では思います。却下されていなければ私は今でもOSSと程遠い場所にいたと思います。

さて、話を戻しますと、これらの環境を構築したのはひとえに「自分の作業を楽にしたい」という想いからでした。そんな自分が次に目を付けたのがCI/CDというものでした。どうやらJenkinsというのを使って自動化するのがナウいらしいと…

導入


Jenkinsに目を付けたのは良いのですが、当時かなり忙しく、検証・導入する時間が取れませんでした。そんな時ですが、所謂SIの闇的なので詳しくは書けないのですが不可抗力で人員を増やしていただけること(頼んだわけではないのですが)になりました。

その増員できてくださった方が私がRemineに上げていたJenkinsを導入したい旨のチケットを見つけてくださいまして「Jenkins使ってみたいんですけど、このチケットやっていいですか?」と言っていただきまして「あ~ぜひぜひお願いします!!」ということで2日後くらいにはJenkinsが稼働していました。Hさんその節は大変ありがとうございました。

自動化と分析


Jenkinsは私たちの開発に様々なものをもたらしてくれました。開発環境へのデプロイやパッケージングといった作業はJenkinsで行うようにしました。次に、警告やエラー、コード量をグラフで見えるようにしました。当時のソースコードはIDEの警告ガン無視されまくりでアレだったのですが、これらの量を減らしていくのが日々の楽しみの一つであったことを記憶しています。

特に開発環境へのデプロイは効果的でフラストレーションの溜まる作業から一気に解放されました。私は作業の自動化とメトリクスの取得、それに基づく改善の重要性をJenkinsから学びました。

別れ


現職では2年ほど前からJenkinsが稼働していましたが、冒頭に書いた通り先々月から別のサービスに移行しました。これにはいくつか理由があるのですが、最も大きいのが「保守したくない」というものでした。「保守したくない」には2つの保守したくないが含まれていました。Jenkinsはオンプレで稼働しており、Jenkinsを停止すればサーバを一台停止できる状態にありました。つまり、サーバを保守したくないというのが一つの保守したくないです。もう一つはJenkinsそのものを保守したくないです。

主に(サーバのスペックがしょぼかったのに結構いろんなものを動かしていた)せいではあるのですが、時よりハングアップすることがありました。また、Dockerで構築しており、なにか追加で使用したいとき(例えばnpmなど)にコンテナにインストールしてイメージ化するなどめんどくさい側面もあり、そういったものをなくしたいというのがありました。移行先のサービスはJenkinsほどは柔軟になにかできるわけではないとは思う(構築に携わってないので良く知らない)のですが、現状十分であり特に問題は起こっていないという感じです。

ただ、弊社のケースでは別のサービスの方がよかったというだけで、Jenkinsそのものは今でもCI/CDの有効な選択肢の一つではあると思います。

Jenkinsは私にとって自動化と可視化、継続的改善の重要性を教えてくれました。これは昨今の開発において非常に重要な要素の一つでJenkinsと出会っていなければ私のITエンジニアとしての価値はもっと低いものとなっていたと思います。私は今でもJenkinsを開発の師匠(のうちの一人)と思っていますし、今後も感謝の気持ちは変わらないと思います。しかし、悲しいことですがどのような関係にも別れは来るものです。この別れが一次のものなのか永遠となるのかは今はわかりませんが…