【CI奮闘記】第3章：CI/CDの気になるデメリット？» CloudBees|テクマトリックス

はじめに

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

登場人物

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

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

連載内容の趣旨

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

CI/CDの気になるデメリット

そういえば以前CIを実施しようとしたけど今は実施していませんよね。何で実施しなかったんですか？（CI奮闘記第一章参照）

いくつか理由はあったんだけど、大きくはイニシャルコストが大きいと感じてしまったからかなぁ。
始めてみようと着手してみたけど、思った以上にいろいろ問題があってね。

なるほど！確かに前職でも始めたタイミングではいろいろありましたね。

前職ではどうやって解消したんだい？

気になる問題1:CI/CDの環境構築の工数としてのコストが大きい？

そうですね。イニシャルコストとの事でしたが、このコストは工数的なコストと金額的なコストどちらですか？

前回はお試しだったからその辺のオンプレPCにJenkinsをインストールしたから金額的にはかからなかったけど、工数がおおきかったなぁ。

確かにJenkinsでフリースタイルジョブやパイプラインを作成していくのも何だかんだ大変ですよね。

そうなんだよね。いろいろ担当者は調べながらやってはくれたんだけど、やっぱり今までやったことない事だったから時間もかかってたね。そのうえうちの部署では自動テストも今まで作成していなかったから、そこまで効果が出ないかなぁとやめてしまったんだ。

確かにCI/CD環境の効果のうち自動テストの有無は大きいですが、まずは一部だけでも自動化することのメリットも大きいですよ！

開発物にも拠りますが、CI/CDの環境を構築するためには往々にして以下の対応が必要になります。

ビルドスクリプトの作成
ユニットテスト等のテストコードの作成
自動デプロイ方法の確立
デプロイ後のUIテスト等のテストコードの作成
フィードバック手段の確立

今まで手動で実施していた場合、これらの事を自動で実行できるように構築してくため、工数がかかります。
しかし、これらの方法をCI/CDで実現しなかった場合、実施していないわけではなく手動で実行していることかと思います。その瞬間では工数があまりかかっていないように見えても、長い期間で見た場合自動化してしまったほうが工数がかからない場合のほうが多いです。導入コストについて試算してみるのもいい方法かと思います。テスト自動化に関してのROIの計算式につきましては、運用する環境に応じて様々な計算方法がございますので書籍やインターネットの情報等で確認いただければと存じます。

また、CI/CDを実現しようとした場合に一気にすべて実現しようとして途中で頓挫するというケースも見受けられます。
もちろんすべて実現できた場合のメリットは大きいですが、一部だけCI/CDを実現したとしても十分メリットがあります。
Aさんが翌日出社したらまだいいですが、長期休暇に入ってしまった、、、などと言ったらリバートをするか、他の人が解読して修正する必要が出てきてしまいます。
これがもしコミットしたタイミングで、「自動でビルドスクリプトが走り、ビルドが完了したら結果が開発者に通知される」という部分だけでも自動化されていたらこういった開発リスクを軽減することができます。

仮にテストコードを作成していなかったとしても、ビルド後のテスト環境への自動デプロイを実現することで、テスト実施のたびにかかるデプロイ操作の労力がなくなり、担当者はすぐにテストに集中することができるようになります。

このように部分的にCI/CDを実現していくことも十分効果的です。

気になる問題2:CI/CDの環境構築の金額としてのコストが大きい？

なるほどね。一気に全部やるんじゃなくて、部分的に実現していくのはいい方法だと思う。

工数面もそうですし、部分的に変えていくのは部署への文化の定着としてもいいと思います。

工数としてのコストはなんとかなりそうだね。そういえば前回はお試しで社内のサーバーをちょっと利用しただけだったから金額としてのコストは無かったけど、実際に本番運用を考えたときにはどうなるんだい？

扱うCI/CDのソフトやサービスにも拠りますが、様々な選択肢がありますよ。確かに金額がかかるケースもありますが、選択肢が広がった分効果的な環境を構築しやすくなっています。

例えばクラウドとか？

そうですね。ハードウェアでいうとそういった選択肢を選ぶことが可能になってきました。ソフトウェア面でもいろいろな選択肢がありますね。あ、あと金額面で大事なことがありました。

なんだい？

CI/CDは新しい仕事を増やすのではなく人の工数を減らしてくれます。その工数と比較して金額を考えるといいと思います。

CI/CDを実現するには金額的なコストはもちろんかかりますが、今まで人が実施していた事を様々なメリットを加えて実現してくれています。
そしてCI/CDというルーティンワーク寄りな業務から離れて、より知的な業務に工数を使うことができるので良い投資なのではないかと一個人として考えています。

CI/CDを実現するためのツールやプラットフォームは様々存在します。
ハードウェアという面から見れば、従来通りにオンプレサーバーに構築することも可能ですし、Amazon Web Serviceのような従量課金制のクラウド上に構築することも可能です。ほかにもSaaS形式でのCIツールを利用することも可能です。

ソフト面では例えばオープンソースのJenkinsを利用することでコストを抑えることが可能です。
無料で使えるというだけではなくCI/CDを実現するために必要な機能はそろっていますし、利用者が多いことから情報収集も容易です。

気になる問題3:静的解析のエラーが多すぎて導入できない？

工数や金額のコストについて、うまく付き合っていく方法はなんとなく理解できたよ。ありがとう。

何よりです。

あと問題になったこととして、試しに静的解析ツールを導入してみようとしたんだけど、ものすごい量のエラーが検知されてしまってね。

どのくらい検知されたんですか？

何千単位だったと思う。今まで静的解析ツール無しでずっと開発してきて初めて導入したから大量に検知されることは理解はできるけど、実際の修正を考えるとね。

まずは全部解消することを目的にするのではなく、今よりも増やさないということから始めてみてはいかがでしょうか。

なるほど。どうしても全部解消してからでないとできないと思ってしまうんだよな。

きれいな状態から始めたほうが良いですが、それ以上増やさないという点からスタートして、徐々に改善していくというのも大切ですよ！

このように既存のプロジェクトに新しい静的解析のツールを導入した場合、初回スキャン時には大量の問題が検知されることが多いです。
プロジェクト開始時からコード規約や静的解析を徹底できれば良いのですが、現実問題なかなかそうもいきません。
当然単純に修正コストもかかりますが、コードの修正に伴うデグレードリスクもあります。
そういった場合、「すべて解消する・問題を0にする」ではなく、まずは「これ以上増やさない」という事から始めて、徐々に良くしていくというスタンスで開始することを推奨します。

気になる問題4:ユニットテストが無い？

あとユニットテストをどうするかだよな。

今まで作成してこなかったんですか？

ユニットテストを作ろうキャンペーンを過去にやったことがあって、その時のユニットテストは残っているんだけどそれ以降の新しいものは無いな。

確かにCI/CD環境の様に毎日実行して通知してくれる環境が無いと陳腐化しがちですものね。

あとどうしても製品コードを書く工数を重視しがちでユニットテストの作成を後回しにしてしまいがちなんだよね。

たしかにその気持ちもわかります。あと自動テスト作成コストや一度作成した自動テストのメンテナンスといったコストもかかりますものね。
ただ、効果のある分野については繰り返し実行できますし、CI/CDを実現すれば、コードに修正が入るたびに自動でユニットテストが実行されるようになります！

確かに作ったシステムは保守していかないといけないからな。これも少しずつ定着させていこうかな。

そうです。しっかり自動テストについてもROIを確認しながら導入できる分野については導入していきましょう！

CI/CDのサイクルを実現する上でユニットテストといった自動で実施できるテストの作成はとても重要です。
ただ、その一方で今まで実施していなかった開発現場にユニットテストを書く文化を定着させるにはとても大変な労力が必要になるでしょう。製品のコードを書くのと同様、もしくはそれ以上に工数がかかります。また、一度作成した自動テストにも保守コストが発生してしまうことも事実です。
そのため、何を自動テストにするかの確認は、自動テスト作成前に実施するべきです。「気になる問題1」の繰り返しになってしまいますが、ROIが向上するのかの検討は必須かと存じます。

CI/CDを実現すれば、人の手を介さずに自動テストが実行されるようになり、自動テストのメリットを加速させます。CI/CDを実現することでコミットの度にユニットテストを実行するようにすれば、ある一定の品質を担保できるようになるでしょう。
例えばJavaであれば、無償のテストフレームワークもありますが、Parasoft Jtestのようなより効率的にテストケースを作成する製品もありますので、そのような製品を利用することでテスト品質であったり作成工数の削減につながり、よりよいCI/CDのフィードバックループの作成が実現できると思います。

Parasoft Jtestについて

Java対応静的解析・単体テストツール Parasoft Jtest

Jtestは、テスト工数の大幅削減とセキュアで高品質なJavaシステムの開発を強力にサポートするJava対応テストツールです。1,000個以上のコーディング規約をもとにソースコードを静的に解析し、プログラムの問題点や処理フローに潜む検出困難なエラーを検出します。さらに、JUnitを用いた単体テストについて、作成、実行、テストカバレッジ分析、テスト資産の管理といった単体テストに係る作業をサポートし、単体テストの効率化を促進します。

まとめ

今回はCI/CDを実現する際の障害になりうる代表的な要素について説明しました。

CI/CDの環境構築の工数としてのコスト
CI/CDの環境構築の金額としてのコスト
静的解析のエラーが多すぎて導入できない
ユニットテスト作成の障壁

いずれの要素も問題になり得ますが、どの問題も折り合いをつけて「徐々に実現していく」ことがCI/CDの実現の第一歩かと思います。

CI/CDは性質上プロジェクトの早いタイミングで実現したほうがメリットが大きいです。
「いま忙しいから」と半年後に延ばすのではなく、まずできるところから環境を改善していき、より良い開発環境の実現を目指しましょう！
(メリットについては前回記載した【CI奮闘記】第2章：CI/CDのメリットって何？を併せてごらんください)

次回からはCI/CDツールの一つである【Jenkins】を利用して、実際にインストールして環境構築をしていきます。

よろしくたのむよ。

サービス紹介

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

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