リリース戦略を支えるCI/CDパ イプライン

CI/CD Test Night #7
https://testnight.connpass.com/event/311263/

Transcript

1. リリース戦略を支えるCI/CD パ イプライン Press Space for next page CI/CD Test Night #7 　March 26, 2024. v0.0.11 @katzumi( かつみ)
2. 自己紹介 「障害のない社会をつくる」をビジョンに掲げている「りたりこ」という会社に所属しています 以下のアカウントで活動しています。 2 / 42 katzumi （かつみ）と申します。 katzchum k2tzumi katzumi
3. 3 / 42 複雑なドメインと向き合っています ハンドブックとは？🤔 圧巻の 1.5K 頁オーバー。レセプト業務の基盤システムを開発しています！
4. お願い 登壇者の励みになるので是非ともご意見やご感想など、フィードバック頂けると助かります mm あとでスライドを公開します 4 / 42 写真撮影、SNS での実況について 　　　🙆‍♀📷 　　　🙅‍♂📹💸 　　　🙅📸👨‍👦‍👦 #cicd_test_night
5. 今日お話すること・話さないこと 5 / 42 スコープ的なお話 🤫話さないこと 詳細な workflow や設定内容 ブランチワークの説明 📣話すこと リリース管理での悩み事 リリース戦略 開発プロセスの見直し 省力化・自動化内容
6. 6 / 42 本プログラムのゴール🏁 プロダクトのリリース戦略を考えるきっかけになれば嬉しいです 想定ターゲット層 リリース間隔が 2 週〜1 ヶ月程度（定期リリース）のプロダクト 開発プロセスにリリース前の受け入れテストがある 品質保証テスト(QAT) 、ユーザー受入れテスト(UAT) 複数リポジトリに分割され依存関係があるサービス マイクロサービスとか、フロントエンド（アプリ含む） ・バックエンドに分かれている 複数チームによる開発 SRE とか Platform Engineering 領域 リリース調整業の軽減
7. 7 / 42 プログラムの流れ 1. リリース管理のつらみ 2. 今回のお話( 事例プロジェクト説明) 3. リリース戦略 4. 運用課題 5. ソリューション 6. 改善結果 7. まとめ Agenda
8. 8 / 42 リリース管理つらみ
9. 9 / 42 リリース管理が大変な理由 だんだんシステムが複雑になり、依存関係が発生してデプロイの難易度があがる 関係者も多数で調整が大変 開発着手順がそのままリリース順とはならない 開発規模がさまざまで尚且つ並行開発される 内外に向けての適切なタイミングでリリース内容を共有しないといけない 必要な情報は受け取り手によっても違うし、多岐にわたる システム全体と関係各位の状況を把握する必要がある 日々変化する状況に対応していかなければならない
10. 10 / 42 リリースやデプロイを判断する人が固定化する問題 この機能はいつリリースだっけ？と脳内リソースを一定消費してしまう リリース都度に判断を求められる プロジェクトリーダー的な人に負担が集中しがち。慣れな部分ではあるけれど
11. 11 / 42 今回のお話 事例となるプロジェクトの説明
12. 12 / 42 プロジェクト概略 自社サービスから接続する BaaS （レセプト業務を扱う API ） スキーマ駆動開発を採用 接続するアプリケーションが複数存在し、それぞれ別チームが運営 シングルテナンシー（single-tenancy ）で利用する想定 稼働するバージョンがサービスによって異なる可能性がある 3 チーム体制で担当サービスを平行開発する 月 1 回程度の定期リリースする リリース前に品質保証テストを実施する 1. センシティブな情報を扱うので、データ管理上のリスクがある。 また、サービスを跨ってのリリース調整は難しいとの判断 ↩︎ 所謂マイクロサービスの 1 つのサービス [1]
13. 13 / 42 悩みごと プロジェクト立ち上げ時の課題認識 バージョン管理の複雑さ 複数バージョンが並行稼働する API 仕様書とアプリケーションの同期 アプリケーションと API 仕様書のバージョンの同期して共有する必要がある スキーマを公開してから、クライアント要望などで見直される可能性 バージョンの把握難易度 クライアントごとや環境ごとにどのバージョンが反映されているかを把握するのが難しい 仕様確認や不具合発生時の問い合わせが複数のチームから発生する
14. 14 / 42 リリース戦略
15. 15 / 42 リリーストレイン 特定の期間ごとにリリースする手法 リリース日を決めてリリースブランチカットを行い、リリースに間に合わなかった機能は 次のリリースタイミングに先送りする
16. 16 / 42 リリースブランチカットするタイミング（git-flow ） 1. 開発スコープを決めて QA リソースも抑えてリリース日を決める 2. 開発開始してテスト可能になったら develop 用 build をテスト環境に開発者がリリース 3. QA がテスト環境で検証。問題があれば 2 からやり直し 4. リリースのリハーサルの前日にタグ付け 5. Release 用 build をステージング環境でリリース・リハーサル実施 6. リリース日に本番環境へリリース 1. develop ブランチへの merge を起点にしてビルド 任意のタイミングで任意のブランチでのビルドも可 ↩︎ 2. タグ付けを起点にしてビルド ↩︎ 連携サービスでのパターン例 [1] [2]
17. 16 / 42 リリースブランチカットするタイミング（git-flow ） 1. 開発スコープを決めて QA リソースも抑えてリリース日を決める 2. 開発開始してテスト可能になったら develop 用 build をテスト環境に開発者がリリース 3. QA がテスト環境で検証。問題があれば 2 からやり直し 4. リリースのリハーサルの前日にタグ付け 5. Release 用 build をステージング環境でリリース・リハーサル実施 6. リリース日に本番環境へリリース 1. develop ブランチへの merge を起点にしてビルド 任意のタイミングで任意のブランチでのビルドも可 ↩︎ 2. タグ付けを起点にしてビルド ↩︎ 連携サービスでのパターン例 [1] [2]
18. 17 / 42 見直し後のリリースブランチカットするタイミング リリース日が未定な状態でもバージョンタグを付ける 開発環境へのデプロイするタイミングでタグを付ける タグ連動したリリースフローの整備 API 仕様書もバージョン管理する アプリケーションにバージョン情報を埋め込む 🖕をアプリケーションのリリースと連動させたバージョン管理 細かくリリースブスブランチを切る戦略
19. 17 / 42 見直し後のリリースブランチカットするタイミング リリース日が未定な状態でもバージョンタグを付ける 開発環境へのデプロイするタイミングでタグを付ける タグ連動したリリースフローの整備 API 仕様書もバージョン管理する アプリケーションにバージョン情報を埋め込む 🖕をアプリケーションのリリースと連動させたバージョン管理 細かくリリースブスブランチを切る戦略
20. 17 / 42 見直し後のリリースブランチカットするタイミング リリース日が未定な状態でもバージョンタグを付ける 開発環境へのデプロイするタイミングでタグを付ける タグ連動したリリースフローの整備 API 仕様書もバージョン管理する アプリケーションにバージョン情報を埋め込む 🖕をアプリケーションのリリースと連動させたバージョン管理 細かくリリースブスブランチを切る戦略
21. 18 / 42 開発プロセス見直しの狙い タグ付けを逐次行うスタイル
22. 18 / 42 開発プロセス見直しの狙い 1. 依存関係のあるサービスのバージョンを明確化 共通の統一したバージョン（= コミット ID ／≠ブランチ）を関係チームと共有した状態にする タグ付けを逐次行うスタイル
23. 18 / 42 開発プロセス見直しの狙い 1. 依存関係のあるサービスのバージョンを明確化 共通の統一したバージョン（= コミット ID ／≠ブランチ）を関係チームと共有した状態にする 2. バージョンを小出しにすることで、フィードバックサイクルを早くする ビックバンリリースにしない あわせてバージョンの差分も見やすくする タグ付けを逐次行うスタイル
24. 18 / 42 開発プロセス見直しの狙い 1. 依存関係のあるサービスのバージョンを明確化 共通の統一したバージョン（= コミット ID ／≠ブランチ）を関係チームと共有した状態にする 2. バージョンを小出しにすることで、フィードバックサイクルを早くする ビックバンリリースにしない あわせてバージョンの差分も見やすくする 3. 参照した API 仕様書のバージョンで、いつでも安心して開発着手ができるようにする バージョン指定で環境を再現可能にすることで、クライアント側で対応するバージョンを選択できる API 仕様書とアプリケーションのバージョンの乖離を発生させない タグ付けを逐次行うスタイル
25. 19 / 42 運用課題
26. 運用負荷上昇のリスク 依存関係の元と先の両方の運用を考える必要がある 20 / 42 それぞれ運用負荷増となる サービス提供側（プロバイダ） タグ付け作業 そもそもタグ付けのルールどうする？🤔 リリースノート作成 ドキュメント反映 リリース前準備や付帯作業 サービス利用側（コンシューマ） 各環境のデプロイの調整 API 仕様書の差分を追うのが大変 バージョン差異の影響度がわからない
27. 運用負荷上昇のリスク 依存関係の元と先の両方の運用を考える必要がある 20 / 42 それぞれ運用負荷増となる サービス提供側（プロバイダ） タグ付け作業 そもそもタグ付けのルールどうする？🤔 リリースノート作成 ドキュメント反映 リリース前準備や付帯作業 サービス利用側（コンシューマ） 各環境のデプロイの調整 API 仕様書の差分を追うのが大変 バージョン差異の影響度がわからない
28. 運用負荷上昇のリスク 依存関係の元と先の両方の運用を考える必要がある 20 / 42 それぞれ運用負荷増となる サービス提供側（プロバイダ） タグ付け作業 そもそもタグ付けのルールどうする？🤔 リリースノート作成 ドキュメント反映 リリース前準備や付帯作業 サービス利用側（コンシューマ） 各環境のデプロイの調整 API 仕様書の差分を追うのが大変 バージョン差異の影響度がわからない
29. 21 / 42 ⚠開発プロセスとして 正しく運用されなければ 絵に描いた餅になる
30. 22 / 42 ソリューション
31. 23 / 42 どう立ち向かうか？
32. 24 / 42 OSS の開発スタイルに倣う
33. 25 / 42 セマンティックバージョニング <version core> ::= <major> "." <minor> "." <patch> SemVer
34. 26 / 42 セマンティックバージョニングとは？ Semantic Versioning おさらい より バージョン番号( <major> "." <minor> "." <patch> ) 間の差分で互換性を表す 1. 基本的に数字 3 つでバージョンを表し、リリース前の不安定なバージョンには alpha や rc などがつくことがある 2. 一番左の数字が大きくなったら後方互換性がない 3. 一番左の数字が 0 のときはどの数字が上がっても後方互換性がない 4. たまに一番左以外の数字があがったときに後方互換性がない場合がある “
35. tagpr
36. 28 / 42 tagpr との出会い k1LoW @k1LoW·Follow これがtagprで実現したかったこと 統制されていながらも自由なリリースの自動化 エイッと踏み込んでくださった @katzchum さんに感謝 katzchum@katzchum おー。自動で作られている！ mergeしちゃっていいかな。ドキドキ github.com/k1LoW/runn/pul… 8:01 PM · Oct 1, 2022 7 Reply Copy link Read more on X
37. 29 / 42 tagpr の動き リリース用のpull request を自動作成し、マージされたら自動でタグを打つtagpr 1. リリース用の pull request が GitHub Actions で自動で作られる バージョン番号が書かれたファイルや CHANGELOG.md を自動更新 2. その pull request をマージするとマージコミットに自動でバージョン tag が打たれる semver 前提
38. 30 / 42 Demo https://github.com/k2tzumi/empowering-release-strategies-cicd-pipelines
39. 31 / 42 tagpr でのリリース＆バージョン管理事例 本スライドは Slidev という Markdown でスライド作成するツールを利用しています Markdown は GitHub でリポジトリ管理しています。 バージョン番号はこれ（スライド執筆時点） 実はこのスライドも管理されていたりします
40. 32 / 42 tagpr まとめ GitHub flow のデメリットを補う最後のピース SemVer によるバージョン管理 バージョン番号で影響度がわかるようになる リリース手順に非常に緩い制約付けがされる リリースの workflow の起点となる CHANGELOG やリリースノートも連動して作成される リリース作業自体がオープン化される 次にリリースされる内容が他のチームからもわかる
41. 33 / 42 改善結果
42. 34 / 42 リリースworkflow で実現したアレコレ 次バージョンでの build 作成 OpenAPI 仕様書公開 S3 静的ウェブサイトホスティングに sync 以下の 3 つのバージョンでの仕様書公開 latest リリースタイミングで反映 次バージョン リリースブランチに merge 時に反映 過去のバージョン OpenAPI の仕様書のバージョン間の差分作成 Tufin/oasdiff で breaking changes を検知 1. ビルドコストを下げる為に現時点では停止中 ↩︎ 実装例です [1]
43. 35 / 42 tagpr のTips 次のバージョン決定が label 連動で制御される Migration 有や OpenAPI 変更有のラベルと連動して Minor アップデートにする [tagpr] minorLabels = migration,oas-change 本リリースなのか？仮リース なのか？判定する方法 tagpr のアクション呼び出し後の outputs.tag を判定して github script 経由で後続の wokflow の dispatch を 呼び分ける 本リリース if: steps.tagpr.outputs.tag != '' 仮リリース if: steps.tagpr.outputs.tag == '' 1. リリースブランチへの merge が通常の Pull Request のものか？ ↩︎ [1]
44. 36 / 42 CD パイプライン全体まとめ ✅はtagpr 標準機能で実現 イベント ワークフロー・アクション リリースブランチ Merge 時 ✅リリース用 PR 作成 次リリースバージョンの API 仕様書作成（swagger-php, redoc ） 次リリースバージョンのコンテナイメージ作成（ECR push ） リリース用 PR Merge 時 ✅リリースタグ付け ✅API バージョン情報書き換 ✅CHANGELOG 更新 ✅リリース（ノート）作成（tagpr+GitHub ） リリースバージョンのコンテナイメージ作成（ECR push ） API 仕様書公開（Latest 反映） API 仕様書変更点まとめ（oasdiff ） チーム開発環境リリース時 タグ指定して runn でEC2 へデプロイ（ssh 自動化ツールとして利用) テスト環境以降リリース時 タグ指定して ecspresso でECS へデプロイ(GitHub Action 経由)
45. 37 / 42 ドキュメントの品質向上への取り組み（CI ） スキーマ駆動開発で仕様書の品質確保が重要 OpenAPI の仕様書の静的チェック stoplightio/spectral で Lint OpenAPI の関連ツールで仕様書を利用可能か？を検証する OpenAPI の仕様書と API の実装が乖離していないか？のチェック runn を利用してリクエストとレスポンスが OpenAPI の仕様書通りか？ テストする
46. 38 / 42 まとめ
47. 39 / 42 tagpr を導入して感じたメリット CI/CD パイプラインを充実させることで運用負荷がかからず開発者体験の向上ができる テスト環境以降のデプロイ作業を各サービスのチームメンバーへタスク移譲できた テスト OK になったバージョンでリリーストレインに乗るイメージ API 変更点の共有を省力化 バージョンアップ時にリリースノートを共有するだけ 最新 API 仕様書をいつでも見られるようにした（遅延なし） 差分もログとして管理される リリースマネジメントが民主化される 次回のリリース内容が見えるようになって、いい感じに協調できる
48. 40 / 42 tagpr の波及効果 行動様式が変わりそうな予感 SRE 部門も使い始めた ベースイメージを tagpr でバージョン管理し、依存しているリポジトリで renovate させる →　共通コンポーネントや、ベースイメージなどプラットフォーム領域と相性が良さそう 細かくリリースを心がけるようになる tagpr がリリース用 PR を纏めてくれることで、細かくリリースをしようとするマインドになる バージョンのトレースがし易くなった ログや監視ツールに API のバージョンを表示さるようにした バージョン齟齬によるエラーが直ぐに判別できる
49. 41 / 42 参考資料＆リンク セマンティック バージョニング 2.0.0 https://semver.org/lang/ja/ Songmu/tagpr https://github.com/Songmu/tagpr リリース用の pull request を自動作成し、マージされたら自動でタグを打つ tagpr https://songmu.jp/riji/entry/2022-09-05-tagpr.html tagpr で実現する Pull Request 上で進める OSS のリリースマネジメント https://k1low.hatenablog.com/entry/2022/10/04/083000 登壇を支える技術 https://zenn.dev/katzumi/articles/technology-supporting-speakers runn https://github.com/k1LoW/runn 1. Demo したリポジトリの説明記事です ↩︎ [1]
50. 42 / 42 ご清聴ありがとうございました