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

Slide 1

Slide 1 text

リリース戦略を支えるCI/CD パイプライン Press Space for next page CI/CD Test Night #7 　March 26, 2024. v0.0.11 @katzumi( かつみ)

Slide 2

Slide 2 text

自己紹介「障害のない社会をつくる」をビジョンに掲げている「りたりこ」という会社に所属しています以下のアカウントで活動しています。 2 / 42 katzumi （かつみ）と申します。 katzchum k2tzumi katzumi

Slide 3

Slide 3 text

3 / 42 複雑なドメインと向き合っていますハンドブックとは？🤔 圧巻の 1.5K 頁オーバー。レセプト業務の基盤システムを開発しています！

Slide 4

Slide 4 text

お願い登壇者の励みになるので是非ともご意見やご感想など、フィードバック頂けると助かります mm あとでスライドを公開します 4 / 42 写真撮影、SNS での実況について　　　🙆‍♀📷 　　　🙅‍♂📹💸 　　　🙅📸👨‍👦‍👦 #cicd_test_night

Slide 5

Slide 5 text

今日お話すること・話さないこと 5 / 42 スコープ的なお話 🤫話さないこと詳細な workflow や設定内容ブランチワークの説明 📣話すことリリース管理での悩み事リリース戦略開発プロセスの見直し省力化・自動化内容

Slide 6

Slide 6 text

6 / 42 本プログラムのゴール🏁 プロダクトのリリース戦略を考えるきっかけになれば嬉しいです想定ターゲット層リリース間隔が 2 週〜1 ヶ月程度（定期リリース）のプロダクト開発プロセスにリリース前の受け入れテストがある品質保証テスト(QAT) 、ユーザー受入れテスト(UAT) 複数リポジトリに分割され依存関係があるサービスマイクロサービスとか、フロントエンド（アプリ含む）・バックエンドに分かれている複数チームによる開発 SRE とか Platform Engineering 領域リリース調整業の軽減

Slide 7

Slide 7 text

7 / 42 プログラムの流れ 1. リリース管理のつらみ 2. 今回のお話( 事例プロジェクト説明) 3. リリース戦略 4. 運用課題 5. ソリューション 6. 改善結果 7. まとめ Agenda

Slide 8

Slide 8 text

8 / 42 リリース管理つらみ

Slide 9

Slide 9 text

9 / 42 リリース管理が大変な理由だんだんシステムが複雑になり、依存関係が発生してデプロイの難易度があがる関係者も多数で調整が大変開発着手順がそのままリリース順とはならない開発規模がさまざまで尚且つ並行開発される内外に向けての適切なタイミングでリリース内容を共有しないといけない必要な情報は受け取り手によっても違うし、多岐にわたるシステム全体と関係各位の状況を把握する必要がある日々変化する状況に対応していかなければならない

Slide 10

Slide 10 text

10 / 42 リリースやデプロイを判断する人が固定化する問題この機能はいつリリースだっけ？と脳内リソースを一定消費してしまうリリース都度に判断を求められるプロジェクトリーダー的な人に負担が集中しがち。慣れな部分ではあるけれど

Slide 11

Slide 11 text

11 / 42 今回のお話事例となるプロジェクトの説明

Slide 12

Slide 12 text

12 / 42 プロジェクト概略自社サービスから接続する BaaS （レセプト業務を扱う API ）スキーマ駆動開発を採用接続するアプリケーションが複数存在し、それぞれ別チームが運営シングルテナンシー（single-tenancy ）で利用する想定稼働するバージョンがサービスによって異なる可能性がある 3 チーム体制で担当サービスを平行開発する月 1 回程度の定期リリースするリリース前に品質保証テストを実施する 1. センシティブな情報を扱うので、データ管理上のリスクがある。また、サービスを跨ってのリリース調整は難しいとの判断 ↩︎ 所謂マイクロサービスの 1 つのサービス [1]

Slide 13

Slide 13 text

13 / 42 悩みごとプロジェクト立ち上げ時の課題認識バージョン管理の複雑さ複数バージョンが並行稼働する API 仕様書とアプリケーションの同期アプリケーションと API 仕様書のバージョンの同期して共有する必要があるスキーマを公開してから、クライアント要望などで見直される可能性バージョンの把握難易度クライアントごとや環境ごとにどのバージョンが反映されているかを把握するのが難しい仕様確認や不具合発生時の問い合わせが複数のチームから発生する

Slide 14

Slide 14 text

14 / 42 リリース戦略

Slide 15

Slide 15 text

15 / 42 リリーストレイン特定の期間ごとにリリースする手法リリース日を決めてリリースブランチカットを行い、リリースに間に合わなかった機能は次のリリースタイミングに先送りする

Slide 16

Slide 16 text

16 / 42 リリースブランチカットするタイミング（git-flow ） 1. 開発スコープを決めて QA リソースも抑えてリリース日を決める 2. 開発開始してテスト可能になったら develop 用 build をテスト環境に開発者がリリース 3. QA がテスト環境で検証。問題があれば 2 からやり直し 4. リリースのリハーサルの前日にタグ付け 5. Release 用 build をステージング環境でリリース・リハーサル実施 6. リリース日に本番環境へリリース 1. develop ブランチへの merge を起点にしてビルド任意のタイミングで任意のブランチでのビルドも可 ↩︎ 2. タグ付けを起点にしてビルド ↩︎ 連携サービスでのパターン例 [1] [2]

Slide 17

Slide 17 text

Slide 18

Slide 18 text

17 / 42 見直し後のリリースブランチカットするタイミングリリース日が未定な状態でもバージョンタグを付ける開発環境へのデプロイするタイミングでタグを付けるタグ連動したリリースフローの整備 API 仕様書もバージョン管理するアプリケーションにバージョン情報を埋め込む 🖕をアプリケーションのリリースと連動させたバージョン管理細かくリリースブスブランチを切る戦略

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

18 / 42 開発プロセス見直しの狙いタグ付けを逐次行うスタイル

Slide 22

Slide 22 text

18 / 42 開発プロセス見直しの狙い 1. 依存関係のあるサービスのバージョンを明確化共通の統一したバージョン（= コミット ID ／≠ブランチ）を関係チームと共有した状態にするタグ付けを逐次行うスタイル

Slide 23

Slide 23 text

18 / 42 開発プロセス見直しの狙い 1. 依存関係のあるサービスのバージョンを明確化共通の統一したバージョン（= コミット ID ／≠ブランチ）を関係チームと共有した状態にする 2. バージョンを小出しにすることで、フィードバックサイクルを早くするビックバンリリースにしないあわせてバージョンの差分も見やすくするタグ付けを逐次行うスタイル

Slide 24

Slide 24 text

18 / 42 開発プロセス見直しの狙い 1. 依存関係のあるサービスのバージョンを明確化共通の統一したバージョン（= コミット ID ／≠ブランチ）を関係チームと共有した状態にする 2. バージョンを小出しにすることで、フィードバックサイクルを早くするビックバンリリースにしないあわせてバージョンの差分も見やすくする 3. 参照した API 仕様書のバージョンで、いつでも安心して開発着手ができるようにするバージョン指定で環境を再現可能にすることで、クライアント側で対応するバージョンを選択できる API 仕様書とアプリケーションのバージョンの乖離を発生させないタグ付けを逐次行うスタイル

Slide 25

Slide 25 text

19 / 42 運用課題

Slide 26

Slide 26 text

運用負荷上昇のリスク依存関係の元と先の両方の運用を考える必要がある 20 / 42 それぞれ運用負荷増となるサービス提供側（プロバイダ）タグ付け作業そもそもタグ付けのルールどうする？🤔 リリースノート作成ドキュメント反映リリース前準備や付帯作業サービス利用側（コンシューマ）各環境のデプロイの調整 API 仕様書の差分を追うのが大変バージョン差異の影響度がわからない

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

21 / 42 ⚠開発プロセスとして正しく運用されなければ絵に描いた餅になる

Slide 30

Slide 30 text

22 / 42 ソリューション

Slide 31

Slide 31 text

23 / 42 どう立ち向かうか？

Slide 32

Slide 32 text

24 / 42 OSS の開発スタイルに倣う

Slide 33

Slide 33 text

25 / 42 セマンティックバージョニング ::= "." "." SemVer

Slide 34

Slide 34 text

26 / 42 セマンティックバージョニングとは？ Semantic Versioning おさらいよりバージョン番号( "." "." ) 間の差分で互換性を表す 1. 基本的に数字 3 つでバージョンを表し、リリース前の不安定なバージョンには alpha や rc などがつくことがある 2. 一番左の数字が大きくなったら後方互換性がない 3. 一番左の数字が 0 のときはどの数字が上がっても後方互換性がない 4. たまに一番左以外の数字があがったときに後方互換性がない場合がある “

Slide 35

Slide 35 text

tagpr

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

29 / 42 tagpr の動きリリース用のpull request を自動作成し、マージされたら自動でタグを打つtagpr 1. リリース用の pull request が GitHub Actions で自動で作られるバージョン番号が書かれたファイルや CHANGELOG.md を自動更新 2. その pull request をマージするとマージコミットに自動でバージョン tag が打たれる semver 前提

Slide 38

Slide 38 text

30 / 42 Demo https://github.com/k2tzumi/empowering-release-strategies-cicd-pipelines

Slide 39

Slide 39 text

31 / 42 tagpr でのリリース＆バージョン管理事例本スライドは Slidev という Markdown でスライド作成するツールを利用しています Markdown は GitHub でリポジトリ管理しています。バージョン番号はこれ（スライド執筆時点）実はこのスライドも管理されていたりします

Slide 40

Slide 40 text

32 / 42 tagpr まとめ GitHub flow のデメリットを補う最後のピース SemVer によるバージョン管理バージョン番号で影響度がわかるようになるリリース手順に非常に緩い制約付けがされるリリースの workflow の起点となる CHANGELOG やリリースノートも連動して作成されるリリース作業自体がオープン化される次にリリースされる内容が他のチームからもわかる

Slide 41

Slide 41 text

33 / 42 改善結果

Slide 42

Slide 42 text

34 / 42 リリースworkflow で実現したアレコレ次バージョンでの build 作成 OpenAPI 仕様書公開 S3 静的ウェブサイトホスティングに sync 以下の 3 つのバージョンでの仕様書公開 latest リリースタイミングで反映次バージョンリリースブランチに merge 時に反映過去のバージョン OpenAPI の仕様書のバージョン間の差分作成 Tufin/oasdiff で breaking changes を検知 1. ビルドコストを下げる為に現時点では停止中 ↩︎ 実装例です [1]

Slide 43

Slide 43 text

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]

Slide 44

Slide 44 text

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 経由)

Slide 45

Slide 45 text

37 / 42 ドキュメントの品質向上への取り組み（CI ）スキーマ駆動開発で仕様書の品質確保が重要 OpenAPI の仕様書の静的チェック stoplightio/spectral で Lint OpenAPI の関連ツールで仕様書を利用可能か？を検証する OpenAPI の仕様書と API の実装が乖離していないか？のチェック runn を利用してリクエストとレスポンスが OpenAPI の仕様書通りか？テストする

Slide 46

Slide 46 text

38 / 42 まとめ

Slide 47

Slide 47 text

39 / 42 tagpr を導入して感じたメリット CI/CD パイプラインを充実させることで運用負荷がかからず開発者体験の向上ができるテスト環境以降のデプロイ作業を各サービスのチームメンバーへタスク移譲できたテスト OK になったバージョンでリリーストレインに乗るイメージ API 変更点の共有を省力化バージョンアップ時にリリースノートを共有するだけ最新 API 仕様書をいつでも見られるようにした（遅延なし）差分もログとして管理されるリリースマネジメントが民主化される次回のリリース内容が見えるようになって、いい感じに協調できる

Slide 48

Slide 48 text

40 / 42 tagpr の波及効果行動様式が変わりそうな予感 SRE 部門も使い始めたベースイメージを tagpr でバージョン管理し、依存しているリポジトリで renovate させる →　共通コンポーネントや、ベースイメージなどプラットフォーム領域と相性が良さそう細かくリリースを心がけるようになる tagpr がリリース用 PR を纏めてくれることで、細かくリリースをしようとするマインドになるバージョンのトレースがし易くなったログや監視ツールに API のバージョンを表示さるようにしたバージョン齟齬によるエラーが直ぐに判別できる

Slide 49

Slide 49 text

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]