【CI奮闘記】第2章：CI/CDのメリットって何？» CloudBees|テクマトリックス

この会社ではウォーターフォール式の開発スタイルで開発を進めています。
そのため開発締めのタイミングで開発者はtrunk環境にマージを行い、マージされたコードを評価チームに引き渡し評価をしてもらうというプロセスを踏んでいます。
このような会社でCIを実現した場合のメリットを今回は紹介していきたいと思います。

はじめに

前回のブログでは、CIやCDとは何かという事について説明しました。
前回のブログはこちら
今回はCIを実現するとどういったメリットがあるのかという事について説明していきましょう。

登場人物

吉田：転職したてのエンジニア。前職では積極的にCIやCDという事に取り組みながら開発をしていた。

溝口：入社20年のベテラン。現職の部署の開発経験しかなく、従来通りのウォーターフォールでの開発経験しかない。新しい取り組みには積極的だが、どうしても今までの成功体験に寄ってしまいがち。

連載内容の趣旨

CI/CDについての概要の説明はもちろん、時には実演を伴って一緒に読み進めていくことによりCI/CDを理解し、実践できることを目的としています。

CI/CDのメリットって何？

なんとなくCIやCDはよさそうという事はわかったけど、CIを実現してフィードバックサイクルを早くすると開発者は何が嬉しいんだい？

今の開発方法は、開発締めのタイミングでturnkに全員がマージして開発物をFIXしてから評価チームに渡して評価してもらっていますよね。

不具合発見の早期化のメリット

うん、そうだね。

ちなみに開発期間はどの程度あるのでしょうか？

うちは4カ月を開発期間として開発しているよ。

という事は、開発期間の初めのほうに開発した開発物の評価も4カ月後に行われるわけですよね？
4カ月もたったコードです。バグの修正をしようと思っても、開発者は思い出すところから始めなければならないでしょう。

しかもそれからほかの人の開発物が入ってるから変わってる可能性もあるね。

これが毎日trunkにコミットして自動テストが実施された場合、コミットしてちょっと休憩している間に結果が返ってくるので、すぐにバグの修正を行うことができます。

なるほど。

あと開発締めが終わってから不具合が発見された場合、開発者のアサイン調整が必要になりますよね。その場合次の開発クールへの影響がでてきますし、あまりに発見された不具合が多かった場合には修正のための開発者の増員といったことも考えられます。

確かにいままでなあなあにしてきたけど、本来解放されている開発者に再度不具合修正をしてもらうわけだから後続のプロジェクトにも影響がでるし、人員調整の工数も必要になるね。要員を追加する場合ダイレクトに費用が増加するなぁ。

毎日テストを実施していればリスクを下げることができます！

他にも早期に不具合を報告できることには多くのメリットが挙げられます。

修正が遅れれば遅れるほどソースコードの影響範囲も広くなっていく可能性があり、同じ修正を行うにしても修正コストが多くかかってしまうことが考えられます。それに対し、上記の会話内で述べたように早期にバグが判明することで、書いたソースコードの認識が鮮明なうちに不具合の修正をすることが可能になります。

また、通常は不具合が発見された場合、修正する人をアサインする必要が出てきます。開発締め後のアサインになった場合、それまで開発していた開発者は別の案件に着手している場合が多いでしょう。出荷が近づけば近づくほど、アサインの自由度がなくなります。既知の不具合が修正されないままリリースや、最悪リリースを遅らせるといった場合も考えられます。

不具合修正自体も、原因の特定、修正方法の検討等を行い、修正をして再度テストが必要になります。修正内容の影響度によってはすべて再テストが必要といったこともあり得ます。こういった問題も早期にバグが発見され修正されていれば防げる可能性が高まります。

このように、早期に不具合が発見されることで、修正工数の削減や修正スケジュールや開発内容の調整といったことも可能になります。

自動テストの形骸化を防止

それだけではなくて、たとえば自動テストを書いていないコードを検知するような仕組みを入れておけば必ず自動テストとセットでコミットする習慣ができます。
こういった習慣を実現することでソースコードの品質も向上していきます。

確かに、一度単体テストのソースコードを整備したけど、だんだんと利用されていかなくなったなぁ。

自動テストを作るという事自体も技術が必要ですが、自動テストでより難しいのは自動テストの環境を保守することです。
もともと自動テストがなかった機能のソースコードに対して単体テストの自動化をしたものの、機能のソースコードの作成を優先するあまり対応する単体テストの作成がされず、だんだんと陳腐化していくということはよく聞く話です。
ソースコードをコミットしたタイミングで単体テストが存在しているか確認をしフィードバックするサイクルを実現することで、単体テストを作成する習慣をつけていくことも可能になるでしょう。

属人化された作業・暗黙知の撤廃

開発締めの後は開発物をテストするために評価環境に適用をしますよね。その適用方法はどうしていますか？

高橋さんが頑張って手順書を見ながら適用してくれているよ。

ちなみに高橋さんが休暇した場合はどうなります？

手順書を見ながらほかの人がやると思うけど、ここのところずっと高橋さんがやってくれているからほかの人がやったところは見たことがないなぁ。

そのような状況ですと大抵暗黙知が入り込みますよね。CDを実現すると固定で誰かが張り付いて実施する必要もないですし、作業の属人化や暗黙知が撤廃できます！

確かにそうだね。しかも手順書がひとまずあるから自動化もしやすいね。

この会社では開発期間が終了してから開発したソースコードをコンパイルし、テストを実施するための評価環境に適用をします。
一言で適用といっても開発対象によって適用方法は様々ですし、例えばWebアプリケーションであればミドルウェアのバージョンアップが必要であったりと適用対象の環境の整備も必要になります。そのため手順書を作成して手順書に沿って適用するという場合が多いと思われます。

一人が専任で作業すると、往々にして手順書の更新は滞りがちです。
「手順書の修正が必要な場合でもいわゆる「手癖」で実施してしまい日常の業務は問題なく遂行できるが、引継ぎで手順書通り実施しても実行できない」
こういったケースも良く耳にします。
CDを実現するプロセスの自動化をする中で、こういった暗黙知はすべて明らかになり属人化された作業・活動の撤廃が可能になります。

コード解析を併用し、品質を可視化

そして毎日自動テストを実施できるようになると、ソースコードにある問題の可視化もできるようになります。

ん？どういうことだい？

毎日trunkにソースコードをコミットやマージして自動テストを実施することができるので、現在のソースコードの不具合の状況を確認することができます。ほかにもコード規約があれば、その問題数の推移を毎日確認することができます。

なるほど。開発締め後にコードの品質がわかるんじゃなくって、日々の推移が見れるのであれば事前にいろいろ手を打てるね。

毎日trunkにコードをコミット・マージをすることでtrunkのコードの不具合件数をレポートすることが可能になります。
当然単体テストの不具合数のトレースも可能ですし、コード規約に沿ったコードが書かれているかという静的解析も可能になります。
JavaのツールとしてはFindBugs、SpotBugsやCheckstyle、また弊社取り扱い製品のParasoft Jtestなどが挙げられます。
このような分析結果の推移を可視化することで、マネージャー層は開発スケジュールの調整や、品質に問題のあるチームの分析といったことも可能になりますし、開発者はより品質を意識したソースコードを書く事の習慣をつけることが可能になります。

まとめ

今回はCI/CDを実現した際のメリットについて記載しました。CIというと、【trunkに頻繁にマージをしてフィードバックサイクルを早くする】と一言で表現されがちですが、様々なメリットがあります。

不具合発見の早期化のメリット
- 実装したコードの不具合がすぐに検出されるため、影響範囲が小さいうちに修正できる。
- 不具合発見時にアサイン者の調整コストを下げることができる。

自動テストの形骸化を防止
- コミットと同時にテストが実行されるため、テストが頻繁にメンテナンスされる。

属人化した作業の標準化
- 特定のメンバーしか行えない作業を自動化し、開発体制の単一障害点を無くす。

コード解析を併用し、品質を可視化
- 不具合の検出やコーディング規約チェックを機械的に行うことで一定のコード品質を担保する。

このようなメリットのあるCI/CDです。この機会に読んでいただいた皆さんの開発環境がCI/CDを実現することでどのように良い開発環境へ変化していくか考えるきっかけになれば幸いです。

でもメリットだけじゃなくて、デメリットもあるんだろう？

それについては次回説明します！

サービス紹介

弊社ではCI環境の構築をお手伝いするCI環境構築サービスを行っております。Jenkinsの認定エンジニアが相談に乗りながらCI環境の構築を支援します。
https://cloudbees.techmatrix.jp/ci-solutions/setu p/

「Jenkinsを導入してみたもののプログのような効果がでない」という場合は構築した環境を利用する中での課題を解決し、定着するための支援をするCI/CD運営支援サービスを行っております。
https://cloudbees.techmatrix.jp/ci-solutions/management-support/