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

2024年10月27日JJUG CCC Fall 14:15～

Transcript

1. CI/CDやテスト自動化の 開発プロジェクトへの適用 2024年10月27日 JJUG CCC 2024 Fall #JJUG_CCC #JJUG_CCC_F
2. ディスクレーマー(免責事項)  このプレゼンテーションはどこかの企業や団体を代表して行うものではあ りません。  内容には個人の意見が多分に含まれています。
3. 自己紹介  ゆとり(X: @megascus)  JJUG幹事  中小Sierを転々と勤務のち外資系ベンダー所属  趣味でJava(Jakarta) EEやってます
4. 今回の経緯 Xでなぎせさんと会話してて話したく なったので応募しました。 ※辞退者が出た場合の補欠枠
5. CI/CDの今
6. CI/CDは幻滅期へ  2024年9月27日のPublicKey による記事  ガートナージャパンによ る発表  日本ではKubernetesや CI/CDなどが幻滅期に https://www.publickey1.jp/blog/24/k ubernetescicd2024.html
7. ガートナーによる幻滅期の定義  幻滅期：イノベーションに対する当初の過剰な興奮が収まると、それを打 ち消すように、パフォーマンスの問題、予想を下回る採用ペース、財務的 な投資効果の遅れなどの理由から幻滅感が広がります。  啓発期：(幻滅期の次)一部の早期採用企業が当初の障害を克服し、イノベー ションにメリットを見いだし始めます。早期採用企業の経験から学ぶこと で、企業はそのイノベーションがどこで、どのように多大な価値をもたら すか (もたらさないか) について理解を深めるようになります。 ガートナーによる定義: https://www.gartner.co.jp/ja/research/methodologies/gartner-hype-cycle
8. CI/CDの今  やってみたけれども、うまくいかない (いかなかった)企業が多い  改めてCI/CDをどうやっていくか考えま しょう(このセッションの内容)
9. 改めてCI/CDについて考える
10. CI/CDとは何か CI/CD (継続的インテグレーションおよび継続的デリバリー/デプロイメントの 略) は、ソフトウェア開発ライフサイクルを最適化し、加速す ることを目的としています。 継続的インテグレーション (CI) とは、コード変更を共有ソースコードリポジ トリに自動的かつ頻繁に取り込む手法のことです。継続的デリバリーまたは デプロイメント (CD) は 2 つの部分からなるプロセスで、コード変更の統合、 テスト、デリバリーを指します。継続的デリバリーは、本番環境への自動デ プロイは行わずその手前までを守備範囲としますが、継続的デプロイメント は、更新内容を本番環境に自動的にリリースします。 Red Hatによる定義: https://www.redhat.com/ja/topics/devops/what-is-ci-cd
11. プロジェクトとは何か プロジェクトとは、特定の目的を達成するためや、新しい事業・業務などを 成功させるためにおこなう業務のことで、明確な期限が定められてい ることが、定義としてあげられます。 また、プロジェクトの成功とは、定められた期間内に目標を達成することを 指すため、厳格なスケジュール管理や進捗管理が必須になります。 Chatworkによる定義: https://go.chatwork.com/ja/column/efficient/efficient-388.html
12. プロジェクトの何を自動化するか  プロジェクトで何をやろうとしているのかを理解する必要がある  CI/CDという手法を脳死で適用しても効果は出ない 例)[任意の業務パッケージ]を入れたら業務改善ができて売り上げ百倍 [任意の業務パッケージ]を入れたけれども結局使われない
13. 開発プロジェク トでのCI/CDの 取り組み  期限の決められたプロジェクトでの開発業務 に自動化を取り込んでいく  CI/CDと大仰な名前がついているけれども、や りたいことはタスクの自動化  自分たちの業務の何を自動化していくべきか を理解する必要
14. 開発プロジェクトの理解
15. 自分たちの業務を理解するということ  自分たちが何を目的としているかを知ることで正しく業務改善ができる  その中には自動化も含まれる  業務の中で何に時間がかかってるのかを正しく理解することで最適化が行 える  すでに時間がかかってないことを改善しても効果が薄い  業務を理解しないまま最適化をしようとすると手段が目的になってしまう 場合がある  SvnではなくGitを使ってればモダンな開発ができている  教科書通りにCI/CDを入れようとして反対される
16. 開発プロジェクトとは  顧客からシステムを作りたいという要望を受けて開始されるプロジェクト  要件定義、設計、開発、テスト、本番へのリリース(納品)と進む  ほとんどの場合にウォーターフォールで進む 画像: https://www.celf.biz/campus/system_development01/
17. 開発プロジェクトの特徴  システムリリースまでを目的として発注されたものが多い  要件定義、設計、開発からリリースまでが分割発注されることが多い  CI/CDが必要になるのは開発からリリースまでのフェーズ  要件定義、設計フェーズに関しては準委任契約、開発からリリースの部分 については請負契約(受託開発)となることが多い  設計フェーズも請負契約となる場合がありますが、本筋から関係ないので無視し てください ※このセッションでは開発からリリースの部分のみ扱います。
18. 開発プロジェクト はリリースまでが 目的  いかにリリースするのかが重要になる  リリースができない事には受け入れが行えない =リリースしないとお金がもらえない  要件にあってもリリースに必要ない事については 優先度が落とされる  リリース後にすぐに使わない機能は別途納品も  リリースすることに必要なことのみ改善(自動化) の余地がある  リリース後に多少大変になってもしょうがない
19. 開発プロジェクトに CI/CDを適用していく
20. 業務ルールの確認 自分たちがどのようなルールに基づいて開発をしているかの確認  契約に基づく納品対象、スケジュール等  システム開発/管理規定などの(顧客側)社内ルール  システム開発/管理規定などの(請負側)社内ルール  PMBOKなどの一般的な開発標準手法  PCI DSS等の業界標準、規制
21. 一般的な開発ルール例  プログラマは自分のPCで開発を行う  プログラマが開発したコードは上位者がレビューを行う必要がある  本番サーバーで実行する前に開発サーバー、ステージングサーバーを経由する  開発サーバーで結合テストを行う  ステージングサーバーでシステムテストを行う  本番昇格前の本番サーバーでユーザー受入テストを行う  全てが完成した段階で検収を行い云々  プログラムの本番稼働前には役員承認が必要である  本番稼働しているプログラムは何かを管理する必要がある
22. バージョン管理システムの導入  納品物の進捗を管理していく  あいまいで良ければExcel等で進捗管理をするのも可  GitやSVNはテキスト(ソースコード)を管理するのに特化している  必要に応じてバイナリのバージョン管理ができるツールを併用する必要あり  ソースコードだけではなく、レビュー履歴等も管理できる場合がある  GitHubのプルリクエスト運用等
23. CI/CDサーバーの導入  何かのイベントを基に定期的に自動的に処理を行っていくサーバー  Windowsスケジューラーでもいいし、CRONでも良い、RPA等も  CI/CDサーバー用に開発されたものもありCI/CDを行いやすいような機能が 付いている  Jenkins、github actions、TeamCity、Tekton、Algo CDなどなど  CI/CDサーバーに日常的に行う作業を自動化させる  CI/CDサーバーの多くがコマンドラインしか対応していないのはネック
24. 初心者にはJENKINS がおすすめ 世の中を見るとJenkinsは古いみたいな 情報が多いが・・・・  GUIでグラフィカルに設定、確認が行 える  ローカルで動作できるため、手元の 処理と同じ感覚で自動化が行える  多くのプラグインが存在し、拡張性 に困らない 有償でも構わない場合や、GUIが必要 ない場合、CI/CDに慣れたら他のツール も検討
25. 各種業務処理のCI/CDへの取り込み  複数回、手間のかかる処理を優先的に自動化する  簡単に行えることから行うことで効率が上がる  変更できる場合は業務ルールの見直しを検討する  一部だけでも自動化することで手間が減る  すべての自動化は目的としない  手段と目的の入れ替わり、自動化しないほうが良い事もある
26. CI/CDへ取り込む例: 開発サーバーへのデプロイ 業務ルール:  開発サーバーで結合テストを行う。 結合テストで見つかった不具合を開発サーバーに素早く取り込む必要がある ので、適時自動的に取り込めるようにする。 バージョン管理システムからソースコードを取得し、開発サーバーに反映す る。 再起動がかかる場合、開発サーバーでテストを行っている人の作業を止めて しまうため、リリースタイミングについては要検討。
27. CI/CDへ取り込む例: ステージングサーバーへのデプロイ 業務ルール:  ステージングサーバーでシステムテストを行う。 基本的には開発サーバーと同じ。 開発サーバーよりも不具合の検出数が少ないことが想定される、単体テスト に比べて1テスト項目毎のテスト実施時間が長いので、リリースタイミング は開発サーバーよりも少なくする。
28. CI/CDへ取り込むのに検討が必要な例: 本番サーバーへのデプロイ 業務ルール:  本番昇格前の本番サーバーでユーザー受入テストを行う。  全てが完成した段階で検収を行い云々。  プログラムの本番稼働前には役員承認が必要である。  本番稼働しているプログラムは何かを管理する必要がある。 本番稼働前に役員承認が必要であるため、簡単にできてしまうと逆に問題と なる場合がある。 本番稼働しているプログラムは何かを管理する必要があるため、ビルドまで は自動化し、何かしらを使ってバージョン管理をする必要がある。 →ビルドから本番ライブラリの保存までは自動化する。
29. 業務を見直してCI/CDへ取り込む例: ソースコードレビュー 業務ルール:  プログラマが開発したコードは上位者がレビューを行う必要がある。 現実的にすべてのレビューを行うのは無理なので静的解析ツール等を併用する。 レビューの目的については詳細な確認が必要(例)：  プログラマーの技量アップ(ノウハウ共有)のため  目で見てわかる程度の不具合の検出  不正なコード、ライブラリが含まれていないかどうか
30. 静的解析の取り込み(1)  既存のバグパターンに一致するソースコードを見つけ出してくれる。  いわゆるLint  人の目で見て確認するよりも素早く、何回でも確認できるのが特徴。 Javaでは文字列の比較には equalsメソッドを使用しなければいけない
31. 静的解析の取り込み(2) 静的解析ツールの結果を表示するだけだと機能が足りない  CI/CDにそのまま設定しても誰も見なくなる  作った人に対してメール/チャットツール等で通知する仕組みが必要  コミットしたタイミング、もしくは開発サーバー(結合テスト環境)へのデプ ロイのタイミングで自動的に実施することがおすすめ
32. 人の目で見てのレビュー 自動化はしないのですけれども・・・・・  静的解析を実施することで指摘件数は大幅に削減できる  実績値として1/10以下  静的解析の直し方がすごい場合があるのでレビューは必要  静的解析は簡単なパターンマッチでしかないので、引っかからないように無駄に 複雑にするとか・・・  限界があるので人の目だけには頼らない  サーバー環境にふるまい検知をするアンチウィルスソフトを入れる等
33. (参考)XZ UTILS 人の目で見て行うレビューには限界が存在する。  2024年3月に発生したLinuxパッケージにバックドアが仕掛けられた事件  OSSに対して脆弱性のあるコードがコミットされていた  攻撃者はテスト用のバイナリファイルなどを利用し見た目とは違うコード を動作させることに成功 (参考) XZ Utilsにバックドア攻撃が行われるまでのタイムラインまとめ https://gigazine.net/news/20240403-timeline-of-xz-open-source-attack/
34. CI/CDへ取り込まない例: テスト自動化 業務ルール:  開発サーバーで結合テストを行う。  ステージングサーバーでシステムテストを行う。  本番昇格前の本番サーバーでユーザー受入テストを行う。 プロジェクト内でテストを行う回数が数回程度であるので、テストを自動化して も割に合わない。 テスト自体は本番サーバーで動くものではないため、納品対象ではない。
35. テスト自動化のための基礎知識 ～とはいっても保守フェーズのために自動化したい～ テスト自動化のためのコストに見合った成果が出るのはテストを最低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
36. テスト自動化のための基礎知識 ～テスト自動化の費用対効果がぶれる原因～  自動テストで何を行うかが不明瞭  自動化しやすいテストと自動化しにくいテスト ⇒費用対効果を出したい場合は自動化しやすいテストのみ自動化し、手動テ ストを併用するべき。
37. どうしてもプロジェクト内でテスト自動 化したい場合  納品対象として自動テストを入れる(大前提)  自動テストは本番システムの一部であり重要であるというコンセンサスを 構築する  システム開発費が自動テストの分だけ増えることを許容する 現実的にはプロジェクトが完了してから別予算で自動テストを作成する  標準テストケースの自動化 ※標準テストケースは回帰テスト用に作成するミニマムなテストケース
38. (その他)CI/CDでのメトリクスの取得 CI/CDで日々の管理業務の一部を自動化する場合がある。その際にメトリク スを取得して進捗管理や品質管理を行うことができる。  コード行数、クラス数、画面数など  静的解析によるバグ検知数  循環的複雑度  (JUnitによる)テストケース数
39. (その他)CI/CDでのメトリクスの取得時の 注意 自動的に取得するメトリクスはいくつかの問題点を抱える。  暗数を明らかにしやすい  手動で取得するメトリクスに比べて取りこぼしが少ないため数値が大きくなりや すい  過去のプロジェクトの実績と比較する場合にバグ検知数が多い＝品質が悪いと判 断される原因となる  指標をハックしやすい  目で見て確認しないと怪しい値になっていることがある  空のテストケース、無意味なロジックで行数を稼ぐなど
40. まとめ
41. まとめ  CI/CDは幻滅期にはいった  単純に行うだけでは意味が無いことに気が付かれている  業務ルールを理解する必要がある  自動化するべきもの、しなくてよいものの判断ができる  すべてを自動化はしない  取捨選択することで効果アップ