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