1.はじめに
※ 本投稿は、Jenkinsの具体的な導入方法等を説明するものではありません。
個人開発の中で、「Jenkins」や「Travis CI」は以前から使っていましたが、今回初めて実際の業務でJenkinsの導入を行う機会をいただきました。
その中で見えてきた問題点と課題を戒め(本当に失敗ばかりでした.....)として、そして同じような境遇で導入を検討している方に対して、少しでも私が体験したような失敗を繰り返さないように、参考になればという思いで書かせていただきます。
2.概要
- WindowsServer 2016 がJenkinsを導入するインテグレーションサーバー
- 開発手法はウォータフォール型の開発手法を採用
- CI環境構築の話はプロジェクト開始当初から話題に上がってはいたが、設計等が優先されサーバーの提供が遅れた。
- 自動化だけに焦点が当たっており、Jenkinsの本格的な導入を開始したのが開発後半になってから。
- Gitを今回初の導入
- いよいよ本格的な運用テスト開始という状況になって、Jenkinsが何も用意されてないことに気がつく...
など、今改めて書き出していると、「いやいや、問題だらけ
！！！」と叫びたくなるような状況でアサインされたなと...
3.問題点と課題
#1 Jenkinsを神ツールだと思っている
恐らくすべての問題がここに集約されるのではないかと個人的には思っています。
断言できるのは,,,
- Jenkinsは神ツールではありません。
- Jenkinsを導入するだけでは、何も楽になりません。
最初にこれを理解してもらう必要があります。案外見落としやすいところですが、ここは時間をかけるべきところです。
「Jenkinsとは何か？CI/CDとは何を指すものなのか？」ということJenkinsを使うメンバー全員で触りだけでも良いので理解しておく必要があります。
ここでいう「メンバー全員」とは開発者側だけの話ではありません。システムを運用していくメンバーも含まれます。
この部分は蔑ろにして実装・構築ばかり進めてしまうと、何かあるたびに「Jenkinsで自動化を！」を合言葉のように言われることになります。
下記の投稿にもある通り、Jenkinsとして本当にできることは、豊富なプラグインや簡略化されたGUIを通して自動化の枠組みを提供することのみです。
Jenkins単体、Jenkinsそのものにすべてを自動化する機能があるわけではありません。
#2 運用者・開発者間で生じる温度差
これは上の「#1 Jenkinsを神ツールだと思っている」とほぼ同じような内容ですが、運用者・開発者側に温度差がある場合、早いうちにそれを解消する必要があります。
「開発はお願いします!」「どうやって運用されるのか詳しいことは知りません。」では、そもそも何のためにJenkinsを利用しているのか分かりません。
Jenkinsを利用していく上で、運用者側・開発者側の双方の視点から「システム開発全体のプロセス構築」を行っていく必要があります。
このプロセス構築が出来ているからこそ,,,
- 「自動化できること。」
- 「自動化できないこと。」
- 「自動化すべきこと。」
- 「自動化すべきではないこと。」
これらの区別ができ、その中で自動化が求められる部分がJenkinsのJobとして形作られていきます。
システム開発に関わる大きなプロセスは同じかもしれませんが、その大きなプロセスの中には、そのシステム特有、職場環境特有のプロセスが必ず含まれています。
そこも加味した上で、システム開発全体のプロセス構築を行っていくことが必要になると、私は思っています。
#3 ウォータフォール型開発との相性
今回、私自身がJenkinsを構築した環境ではウォータフォール型開発が行われていましたが、お世辞にも相性が良いとは言えませんでした。
今回の環境がそうだっただけかも知れませんが、ウォータフォール型の開発ではJenkins導入により受けられるフィードバックの恩恵が他の開発手法に比較して小さいように感じました。
ウォータフォール型開発では実際に動く製品が、利用者や運用者の元に届くのが比較的遅い時期になりがちです。
せっかくJenkinsを用意して、CIを行おうとしても,,,
- 開発サーバーの提供時期は設計フェーズ終了後から。
- ステージング・本番サーバーの提供時期は運用テストフェーズから。
など諸々の事情により、DeployができずにBuild専用マシンになってしまうことがあります。
Buildマシンとなった場合でも、適格なテストフィードバック、コード評価を行っていれば、CIの恩恵を享受することはできます。
しかし、Deployを早期から実行できないため、運用フェーズ移行時の問題発覚が遅れてしまいがちです。
#4 導入時期
これは今回の環境構築中に一番後悔しているところです。
CI環境構築はいつから着手するべきなのか、私は過去の自分に対して、声を大にして言いたい....
「プロジェクトの開始と同時期だ
！！！！」と。
開発に着手し始めてからでは遅いです。ある程度形になってからなんてのは、論外です。
そもそもCI：継続的インテグレーションは1日に何度もビルドを実行し、ソフトウェアをインテグレーションしたときに発生するさまざまな問題を早期に検出し、フィードバックサイクルを短くして、ソフトウェア開発の品質と生産性を向上させる仕組みのことです。
開発に着手するときには、すでに用意されていることが望ましいもので、開発と並行しながらフィードバックを行い、育てていくものです。
#5 フィードバック
「自動化」という言葉の引力に負けて、忘れがちですが、CIにはフィードバックが欠かせません。
重要なことなのでもう一度いいます。CIにはフィードバックが欠かせません。
「自動化」という言葉が持つ力は偉大なので、フィードバックをせずに終わってしまう人がいますが本当にもったいない。
「Jenkins実践入門 ~ビルド・テスト・デプロイを自動化する技術~」には
’’継続的インテグレーションの真価はフィードバックにあります。’’
’’ビルドの結果を確認しないとJenkinsの価値はないも同然です。’’
とまで書かれています。(私はここまでは言えませんが、本当にフィードバックは大切です。)
CI導入のメリットはプロセスの自動化、生産性の向上、更新の即時反映、そして短時間でのバグの発見と対処などが挙げられます。
自動化がなされることで、生産性が向上した。というのは非常に分かりやすいため、これがCIの効果と思われがちですが、それはメリットの一つです。
「短時間でのバグの発見と対処」を行うためにはフィートバックが必要です。
わかりやすいので、成功した/失敗しただけに目が行ってしまいますが、
- コンソール出力を確認する
- ビルドにかかった時間を確認する
- テスト結果と実行時間を確認する
- コミット数と変更数を確認する
- インスペクションツールを使って、コーディング規約違反を検知する
などフィードバックで確認すべきことはたくさんあります。
ここから、自分たちの開発に対して足りないこと、改善すべきことを考えていくことが、汎用的な生産性の向上につながっていきます。
「コミット数が急激に増えているから、コミットの単位を見直してみよう。」
「ビルドに時間がかかっているので、ビルドの構成を見直してみよう。」
など、フィードバックから得られる改善点はたくさんあります。
4.さいごに
本当にたくさんの失敗をしましたが、個人開発だけでは得られない経験をすることができました。
私と同じような境遇で、Jenkinsの導入を検討されている方がいれば、少しでも導入前の心構えや準備の一環として参考にしていただければと思います。