CI/CDやテスト自動化の開発プロジェクトへの適用

by Satoshi Seto

Slide 1

Slide 1 text

CI/CDやテスト自動化の開発プロジェクトへの適用 2024年10月27日 JJUG CCC 2024 Fall #JJUG_CCC #JJUG_CCC_F

Slide 2

Slide 2 text

ディスクレーマー(免責事項)  このプレゼンテーションはどこかの企業や団体を代表して行うものではありません。  内容には個人の意見が多分に含まれています。

Slide 3

Slide 3 text

自己紹介  ゆとり(X: @megascus)  JJUG幹事  中小Sierを転々と勤務のち外資系ベンダー所属  趣味でJava(Jakarta) EEやってます

Slide 4

Slide 4 text

今回の経緯 Xでなぎせさんと会話してて話したくなったので応募しました。 ※辞退者が出た場合の補欠枠

Slide 5

Slide 5 text

CI/CDの今

Slide 6

Slide 6 text

CI/CDは幻滅期へ  2024年9月27日のPublicKey による記事  ガートナージャパンによる発表  日本ではKubernetesや CI/CDなどが幻滅期に https://www.publickey1.jp/blog/24/k ubernetescicd2024.html

Slide 7

Slide 7 text

ガートナーによる幻滅期の定義  幻滅期：イノベーションに対する当初の過剰な興奮が収まると、それを打ち消すように、パフォーマンスの問題、予想を下回る採用ペース、財務的な投資効果の遅れなどの理由から幻滅感が広がります。  啓発期：(幻滅期の次)一部の早期採用企業が当初の障害を克服し、イノベーションにメリットを見いだし始めます。早期採用企業の経験から学ぶことで、企業はそのイノベーションがどこで、どのように多大な価値をもたらすか (もたらさないか) について理解を深めるようになります。ガートナーによる定義: https://www.gartner.co.jp/ja/research/methodologies/gartner-hype-cycle

Slide 8

Slide 8 text

CI/CDの今  やってみたけれども、うまくいかない (いかなかった)企業が多い  改めてCI/CDをどうやっていくか考えましょう(このセッションの内容)

Slide 9

Slide 9 text

改めてCI/CDについて考える

Slide 10

Slide 10 text

CI/CDとは何か CI/CD (継続的インテグレーションおよび継続的デリバリー/デプロイメントの略) は、ソフトウェア開発ライフサイクルを最適化し、加速することを目的としています。継続的インテグレーション (CI) とは、コード変更を共有ソースコードリポジトリに自動的かつ頻繁に取り込む手法のことです。継続的デリバリーまたはデプロイメント (CD) は 2 つの部分からなるプロセスで、コード変更の統合、テスト、デリバリーを指します。継続的デリバリーは、本番環境への自動デプロイは行わずその手前までを守備範囲としますが、継続的デプロイメントは、更新内容を本番環境に自動的にリリースします。 Red Hatによる定義: https://www.redhat.com/ja/topics/devops/what-is-ci-cd

Slide 11

Slide 11 text

プロジェクトとは何かプロジェクトとは、特定の目的を達成するためや、新しい事業・業務などを成功させるためにおこなう業務のことで、明確な期限が定められていることが、定義としてあげられます。また、プロジェクトの成功とは、定められた期間内に目標を達成することを指すため、厳格なスケジュール管理や進捗管理が必須になります。 Chatworkによる定義: https://go.chatwork.com/ja/column/efficient/efficient-388.html

Slide 12

Slide 12 text

プロジェクトの何を自動化するか  プロジェクトで何をやろうとしているのかを理解する必要がある  CI/CDという手法を脳死で適用しても効果は出ない例)[任意の業務パッケージ]を入れたら業務改善ができて売り上げ百倍 [任意の業務パッケージ]を入れたけれども結局使われない

Slide 13

Slide 13 text

開発プロジェクトでのCI/CDの取り組み  期限の決められたプロジェクトでの開発業務に自動化を取り込んでいく  CI/CDと大仰な名前がついているけれども、やりたいことはタスクの自動化  自分たちの業務の何を自動化していくべきかを理解する必要

Slide 14

Slide 14 text

開発プロジェクトの理解

Slide 15

Slide 15 text

自分たちの業務を理解するということ  自分たちが何を目的としているかを知ることで正しく業務改善ができる  その中には自動化も含まれる  業務の中で何に時間がかかってるのかを正しく理解することで最適化が行える  すでに時間がかかってないことを改善しても効果が薄い  業務を理解しないまま最適化をしようとすると手段が目的になってしまう場合がある  SvnではなくGitを使ってればモダンな開発ができている  教科書通りにCI/CDを入れようとして反対される

Slide 16

Slide 16 text

開発プロジェクトとは  顧客からシステムを作りたいという要望を受けて開始されるプロジェクト  要件定義、設計、開発、テスト、本番へのリリース(納品)と進む  ほとんどの場合にウォーターフォールで進む画像: https://www.celf.biz/campus/system_development01/

Slide 17

Slide 17 text

開発プロジェクトの特徴  システムリリースまでを目的として発注されたものが多い  要件定義、設計、開発からリリースまでが分割発注されることが多い  CI/CDが必要になるのは開発からリリースまでのフェーズ  要件定義、設計フェーズに関しては準委任契約、開発からリリースの部分については請負契約(受託開発)となることが多い  設計フェーズも請負契約となる場合がありますが、本筋から関係ないので無視してください ※このセッションでは開発からリリースの部分のみ扱います。

Slide 18

Slide 18 text

開発プロジェクトはリリースまでが目的  いかにリリースするのかが重要になる  リリースができない事には受け入れが行えない =リリースしないとお金がもらえない  要件にあってもリリースに必要ない事については優先度が落とされる  リリース後にすぐに使わない機能は別途納品も  リリースすることに必要なことのみ改善(自動化) の余地がある  リリース後に多少大変になってもしょうがない

Slide 19

Slide 19 text

開発プロジェクトに CI/CDを適用していく

Slide 20

Slide 20 text

業務ルールの確認自分たちがどのようなルールに基づいて開発をしているかの確認  契約に基づく納品対象、スケジュール等  システム開発/管理規定などの(顧客側)社内ルール  システム開発/管理規定などの(請負側)社内ルール  PMBOKなどの一般的な開発標準手法  PCI DSS等の業界標準、規制

Slide 21

Slide 21 text

一般的な開発ルール例  プログラマは自分のPCで開発を行う  プログラマが開発したコードは上位者がレビューを行う必要がある  本番サーバーで実行する前に開発サーバー、ステージングサーバーを経由する  開発サーバーで結合テストを行う  ステージングサーバーでシステムテストを行う  本番昇格前の本番サーバーでユーザー受入テストを行う  全てが完成した段階で検収を行い云々  プログラムの本番稼働前には役員承認が必要である  本番稼働しているプログラムは何かを管理する必要がある

Slide 22

Slide 22 text

バージョン管理システムの導入  納品物の進捗を管理していく  あいまいで良ければExcel等で進捗管理をするのも可  GitやSVNはテキスト(ソースコード)を管理するのに特化している  必要に応じてバイナリのバージョン管理ができるツールを併用する必要あり  ソースコードだけではなく、レビュー履歴等も管理できる場合がある  GitHubのプルリクエスト運用等

Slide 23

Slide 23 text

CI/CDサーバーの導入  何かのイベントを基に定期的に自動的に処理を行っていくサーバー  Windowsスケジューラーでもいいし、CRONでも良い、RPA等も  CI/CDサーバー用に開発されたものもありCI/CDを行いやすいような機能が付いている  Jenkins、github actions、TeamCity、Tekton、Algo CDなどなど  CI/CDサーバーに日常的に行う作業を自動化させる  CI/CDサーバーの多くがコマンドラインしか対応していないのはネック

Slide 24

Slide 24 text

初心者にはJENKINS がおすすめ世の中を見るとJenkinsは古いみたいな情報が多いが・・・・  GUIでグラフィカルに設定、確認が行える  ローカルで動作できるため、手元の処理と同じ感覚で自動化が行える  多くのプラグインが存在し、拡張性に困らない有償でも構わない場合や、GUIが必要ない場合、CI/CDに慣れたら他のツールも検討

Slide 25

Slide 25 text

各種業務処理のCI/CDへの取り込み  複数回、手間のかかる処理を優先的に自動化する  簡単に行えることから行うことで効率が上がる  変更できる場合は業務ルールの見直しを検討する  一部だけでも自動化することで手間が減る  すべての自動化は目的としない  手段と目的の入れ替わり、自動化しないほうが良い事もある

Slide 26

Slide 26 text

CI/CDへ取り込む例: 開発サーバーへのデプロイ業務ルール:  開発サーバーで結合テストを行う。結合テストで見つかった不具合を開発サーバーに素早く取り込む必要があるので、適時自動的に取り込めるようにする。バージョン管理システムからソースコードを取得し、開発サーバーに反映する。再起動がかかる場合、開発サーバーでテストを行っている人の作業を止めてしまうため、リリースタイミングについては要検討。

Slide 27

Slide 27 text

CI/CDへ取り込む例: ステージングサーバーへのデプロイ業務ルール:  ステージングサーバーでシステムテストを行う。基本的には開発サーバーと同じ。開発サーバーよりも不具合の検出数が少ないことが想定される、単体テストに比べて1テスト項目毎のテスト実施時間が長いので、リリースタイミングは開発サーバーよりも少なくする。

Slide 28

Slide 28 text

CI/CDへ取り込むのに検討が必要な例: 本番サーバーへのデプロイ業務ルール:  本番昇格前の本番サーバーでユーザー受入テストを行う。  全てが完成した段階で検収を行い云々。  プログラムの本番稼働前には役員承認が必要である。  本番稼働しているプログラムは何かを管理する必要がある。本番稼働前に役員承認が必要であるため、簡単にできてしまうと逆に問題となる場合がある。本番稼働しているプログラムは何かを管理する必要があるため、ビルドまでは自動化し、何かしらを使ってバージョン管理をする必要がある。 →ビルドから本番ライブラリの保存までは自動化する。

Slide 29

Slide 29 text

業務を見直してCI/CDへ取り込む例: ソースコードレビュー業務ルール:  プログラマが開発したコードは上位者がレビューを行う必要がある。現実的にすべてのレビューを行うのは無理なので静的解析ツール等を併用する。レビューの目的については詳細な確認が必要(例)：  プログラマーの技量アップ(ノウハウ共有)のため  目で見てわかる程度の不具合の検出  不正なコード、ライブラリが含まれていないかどうか

Slide 30

Slide 30 text

静的解析の取り込み(1)  既存のバグパターンに一致するソースコードを見つけ出してくれる。  いわゆるLint  人の目で見て確認するよりも素早く、何回でも確認できるのが特徴。 Javaでは文字列の比較には equalsメソッドを使用しなければいけない

Slide 31

Slide 31 text

静的解析の取り込み(2) 静的解析ツールの結果を表示するだけだと機能が足りない  CI/CDにそのまま設定しても誰も見なくなる  作った人に対してメール/チャットツール等で通知する仕組みが必要  コミットしたタイミング、もしくは開発サーバー(結合テスト環境)へのデプロイのタイミングで自動的に実施することがおすすめ

Slide 32

Slide 32 text

人の目で見てのレビュー自動化はしないのですけれども・・・・・  静的解析を実施することで指摘件数は大幅に削減できる  実績値として1/10以下  静的解析の直し方がすごい場合があるのでレビューは必要  静的解析は簡単なパターンマッチでしかないので、引っかからないように無駄に複雑にするとか・・・  限界があるので人の目だけには頼らない  サーバー環境にふるまい検知をするアンチウィルスソフトを入れる等

Slide 33

Slide 33 text

(参考)XZ UTILS 人の目で見て行うレビューには限界が存在する。  2024年3月に発生したLinuxパッケージにバックドアが仕掛けられた事件  OSSに対して脆弱性のあるコードがコミットされていた  攻撃者はテスト用のバイナリファイルなどを利用し見た目とは違うコードを動作させることに成功 (参考) XZ Utilsにバックドア攻撃が行われるまでのタイムラインまとめ https://gigazine.net/news/20240403-timeline-of-xz-open-source-attack/

Slide 34

Slide 34 text

CI/CDへ取り込まない例: テスト自動化業務ルール:  開発サーバーで結合テストを行う。  ステージングサーバーでシステムテストを行う。  本番昇格前の本番サーバーでユーザー受入テストを行う。プロジェクト内でテストを行う回数が数回程度であるので、テストを自動化しても割に合わない。テスト自体は本番サーバーで動くものではないため、納品対象ではない。

Slide 35

Slide 35 text

テスト自動化のための基礎知識～とはいっても保守フェーズのために自動化したい～テスト自動化のためのコストに見合った成果が出るのはテストを最低10回以上行う場合。ただし、研究によってこの回数はバラバラになる。(数回～数十回) ※複数回手動で行う場合、最適化が走るので個人的には20回～以上 (参考)テスト自動化でどれくらいの成果が出るのか世の中にある記事を調べた論文 When and what to automate in software testing? A multi-vocal literature review https://www.researchgate.net/publication/301773252_When_and_what_to_automa te_in_software_testing_A_multi-vocal_literature_review

Slide 36

Slide 36 text

テスト自動化のための基礎知識～テスト自動化の費用対効果がぶれる原因～  自動テストで何を行うかが不明瞭  自動化しやすいテストと自動化しにくいテスト ⇒費用対効果を出したい場合は自動化しやすいテストのみ自動化し、手動テストを併用するべき。

Slide 37

Slide 37 text

どうしてもプロジェクト内でテスト自動化したい場合  納品対象として自動テストを入れる(大前提)  自動テストは本番システムの一部であり重要であるというコンセンサスを構築する  システム開発費が自動テストの分だけ増えることを許容する現実的にはプロジェクトが完了してから別予算で自動テストを作成する  標準テストケースの自動化 ※標準テストケースは回帰テスト用に作成するミニマムなテストケース

Slide 38

Slide 38 text

(その他)CI/CDでのメトリクスの取得 CI/CDで日々の管理業務の一部を自動化する場合がある。その際にメトリクスを取得して進捗管理や品質管理を行うことができる。  コード行数、クラス数、画面数など  静的解析によるバグ検知数  循環的複雑度  (JUnitによる)テストケース数

Slide 39

Slide 39 text

(その他)CI/CDでのメトリクスの取得時の注意自動的に取得するメトリクスはいくつかの問題点を抱える。  暗数を明らかにしやすい  手動で取得するメトリクスに比べて取りこぼしが少ないため数値が大きくなりやすい  過去のプロジェクトの実績と比較する場合にバグ検知数が多い＝品質が悪いと判断される原因となる  指標をハックしやすい  目で見て確認しないと怪しい値になっていることがある  空のテストケース、無意味なロジックで行数を稼ぐなど

Slide 40

Slide 40 text

まとめ

Slide 41

Slide 41 text

まとめ  CI/CDは幻滅期にはいった  単純に行うだけでは意味が無いことに気が付かれている  業務ルールを理解する必要がある  自動化するべきもの、しなくてよいものの判断ができる  すべてを自動化はしない  取捨選択することで効果アップ