所属しているチームでCI/CDの有識者として扱われていて、何かあれば聞かれるような、そういう存在で過ごしている。 とはいえ、これまで培った経験だけではそろそろ厳しくなってきている。 今のチームではJenkinsやGitHub Actionsを使っていて、アプリ等をデプロイするためのインフラはすべてIaCとして管理されている。 のだが、デプロイに時間がすごくかかっている。 例えば統合テストを実施する。そのために、現状だとまっさらなところにリソースをデプロイし、そこに対してテストを実施、その後壊す。 この一連の流れに1-1.5時間かかってる。 これは個人的には、遅い。 この制約もあってか、リリース頻度も週に1回前後となっている。 なにがいけないのだろう、というのがもやもやしているそんなとき、CI/CD Conferenceが行われるということで、いくつかの気になった資料を読み込んで改善の材料を探してる。 まずはこれ。 p.12で触れられている継続的リリースのために必要なことが好き。 - リリースのリスク最小化 - オペレーションの自動化 - デプロイの高速化 特に面白かったものをかいつまんでメモする。 ■リリースのリスク最小化 - SLOとエラーバジェット SLOを設定して監視することで、リリースの品質が悪いときはリスクを減らすとか、取る行動の指針に影響を与えるというのはとても面白い。 - デプロイとリリースの分離 Feature Flagでコードの変更のタイミングと機能追加のタイミングを分けるということでDark Lounchと同じだなと思いつつ、目的が違うので視点がいいなあと思った。 ただ、自分も懸念だったけれど、フラグを増やすと、そのフラグ同士で依存関係が発生してしまうなど、辛いことにもなりうるなあというのが心配どころ。 - 段階的リリース 影響範囲を絞るために対象サーバーを絞ったり、ユーザーを絞ったり、本当に必要な人にのみベータリリースしたり。 ■オペレーションの自動化 - 結合テストの自動実行 定期実行で流していたテストをコミットからのトリガーに変更、ということで最初は確かに定期実行とかするものの、まあコミットからトリガーというのは今時だと当たり前かなという感じ。 より面白かったのは、同じ実装に同じテストを何回も走らせないという話。 職場でも当初、結合テストを