CI/CD Conference 2021つまみ食い
所属しているチームでCI/CDの有識者として扱われていて、何かあれば聞かれるような、そういう存在で過ごしている。
とはいえ、これまで培った経験だけではそろそろ厳しくなってきている。
今のチームではJenkinsやGitHub Actionsを使っていて、 アプリ等をデプロイするためのインフラはすべてIaCとして管理されている。
のだが、デプロイに時間がすごくかかっている。
例えば統合テストを実施する。そのために、現状だとまっさらなところにリソースをデプロイし、そこに対してテストを実施、その後壊す。
この一連の流れに1-1.5時間かかってる。
これは個人的には、遅い。
この制約もあってか、リリース頻度も週に1回前後となっている。
なにがいけないのだろう、というのがもやもやしているそんなとき、CI/CD Conferenceが行われるということで、いくつかの気になった資料を読み込んで改善の材料を探してる。
まずはこれ。
数時間かかる週一リリースを毎日何度も爆速でできるようにするまで / CI/CD Conference 2021 - Speaker Deck
p.12で触れられている継続的リリースのために必要なことが好き。
- リリースのリスク最小化
- オペレーションの自動化
- デプロイの高速化
特に面白かったものをかいつまんでメモする。
■リリースのリスク最小化
-
SLOとエラーバジェット
SLOを設定して監視することで、リリースの品質が悪いときはリスクを減らすとか、取る行動の指針に影響を与えるというのはとても面白い。 -
デプロイとリリースの分離
Feature Flagでコードの変更のタイミングと機能追加のタイミングを分けるということでDark Lounchと同じだなと思いつつ、目的が違うので視点がいいなあと思った。
ただ、自分も懸念だったけれど、フラグを増やすと、そのフラグ同士で依存関係が発生してしまうなど、辛いことにもなりうるなあというのが心配どころ。 -
段階的リリース
影響範囲を絞るために対象サーバーを絞ったり、ユーザーを絞ったり、本当に必要な人にのみベータリリースしたり。
■オペレーションの自動化
- 結合テストの自動実行
定期実行で流していたテストをコミットからのトリガーに変更、ということで最初は確かに定期実行とかするものの、まあコミットからトリガーというのは今時だと当たり前かなという感じ。
より面白かったのは、同じ実装に同じテストを何回も走らせないという話。
職場でも当初、結合テストをfeatureブランチでも何度も何度も流していた。ただ、テストの実行時間が伸びてくるにつれて、何でもかんでも毎回テスト、となってしまって、それを待つ時間がもったいない、というような考えに自身やメンバーはシフトしていった。
そこで、結合テストをfeatureブランチでもやりたい時はJenkinsでチェックする（マニュアル）、mainブランチに入った時はチェックに拘らず結合テストをする、という形にすることで対応できた。
自分たちがやっている話と同じ類の話が出てくるとワクワクする。
■デプロイの高速化
- なぜデプロイは速くなくてはならないか
デプロイが速くなければいけない理由は、モニタリングしなければいけない時間が長くなること・ロールバックにかかる時間が長引いてインパクトが残ること、ということでとても合意。そしてなにより、職場ではIn-Placeデプロイしているのだが、わかってはいるけれど、Blue-Greenであるとか、なんらか手を打てないとしんどいところ。
次はこれ。
CyberAgent における OSS の CI/CD 基盤開発 myshoes#CICD2021
GitHub Actionsのself-hosted Runnerのつらみとそれに対する手打ちのためのOSSであるmyshoesの紹介。
myshoesすっごいいけてるなーと思った。
ちょうど職場のインフラチームがGitHub Actionsを整備しているものの、冪等性がないプラス使用方針のアナウンスが甘かったことに起因して、Permission Errorが悉く発生する......。
それに対してこのmyshoesはself-hosted runnerをjobごとに生成してくれる優れもの。
要はGitHub HostedのRunnerと同じ使い勝手を自分がホストしているRunnerで実現できるというわけで結構かっこいい。
ところでこの問題はつい数日前にマージされたPRに含まれていた。（この講演よりも前にOpenになっていたPR自体はウォッチしていた）
ので、もしかすると、今後は冪等性の観点だけでいけば、新しいバージョンへの対応が済めばそれでOK、ということになるかもしれない。
Support configure runner as ephemeral. by TingluoHuang · Pull Request #660 · actions/runner · GitHub
続いてこれ。
高品質・セキュア・スピーディなソフトウェア開発を実現するクラウドネイティブ時代のDevSecOpsとシフトレフト手法 | CI/CD Conference 2021 by CloudNative Days
シフトレフト、要はバグをより前段階の工程で検出・修正するのが大事だよね、という話。
他の講演資料と違って、営業資料的な色合いが強いのだけど、言っている内容自体はセキュリティの観点で勉強になる。
次の3つが実現のポイントとしてあがってる。
- 静的コード解析：Coverity、検知後のレビューも可能っぽい、既出をマークしてレビューを高速化するのは素敵
- 動的解析(IAST=Intaractive Application Security Test)：Seeker、セキュリティ系のアクティビティに合わせて実行
- ソフトウェアコンポジション解析：Black Duck、使用しているOSSに脆弱性が含まれていないかなどを調べる
この辺は目的ごとに色々あるから面白い。自分が見たもののうち、この講演だけは営業職が強い感じがした。資料も参照には登録が必要だったな。
次はこれ。
複数ブランチ運用は『単一のコードベース』と言えるのか / What are your justifications for the multi-branches? - Speaker Deck
これはちょうど最近悩んでいた話。
実はつい最近、Martin Fowlerのこの記事を読んだ。
ソースコードブランチ管理のパターン
原文：Patterns for Managing Source Code Branches
結構昔から、GitLab Flowが好きで、それをチームに導入し運用することが多かった。
Introduction to GitLab Flow | GitLab
ただ、近頃、このブランチングが面倒に感じることがあった。
最低限気になったことを思い浮かべながら運用の具体を振り返ると、
- master -> stagingのときはリリースされる機能の一覧を確認し、確認項目がクリアならMergeしてデプロイ
- staging -> productionはほぼ同じチェックをするだけでMerge
- GitHubのPRでstagingやmasterはmergedになっていることもありPRを作るときに混乱しがちだった（多分GitHub Actionsで自動PR生成くらいしておくべきだったとは思う）
- Rollbackが必要な時、今のやり方だと、各環境でRollbackしなければいけないので手間も混乱もありそう
- というかRollbackが必要な時も基本はRollbackではなくMoving Forwardというか修正する方向で対応、ということにしているので、不具合発生時のダウンタイムが長引きそう
- そういう意味でIn-Placeデプロイになっている現状を変えたいけどそこに時間をまだ投資できていない
という感じで。課題は見え隠れしている感じがする。
問題が起きていないだけで、jeopardize してしまっているというか、危険に晒してしまっていて、他人が今の状況を見たら「本番を舐めているのか」という感想を抱きそう。よくない。
複数ブランチ運用は「単一のコードベース」と言えないと思う。トリさんの記事とMartin Fowlerの記事、そしてチームで成し遂げたいことを押し並べて見てみようと思う。
続いてこれ。
State of DevOps Report 2020/2021から見るCI/CDの始め方 - Speaker Deck
State of DevOps Reportは時々サラッと読んでいたけど、日本語訳してくれている人がいたなんて知らなかった。ありがたい。
4つのメトリクスとして出ている次のものは有名なんだけど、改めて見ていると、今は高〜中程度だな、と。当然のようにエリートに持っていきたいのに現状ではできていない。
- デプロイ頻度
- 変更に要するリードタイム
- 復旧時間
- 失敗の頻度
その後の、「社内基盤は製品。プロジェクトにあらず」、基盤はリリースしたら終わりではない、というのが熱かった。専属で改善することの意義をチーム内では詰めきれずにいる。
必要なチームが必要な形で手を入れればいいのではないかということで、ベースを自分は作ったし、それの使い方のガイドは作ったが、それより先には手を入れることができていない。
開発基盤G ジャーニーとか面白い。完全にステージ3のインフォーマルグループだな今は、とか。
CI/CDを成熟させる3つのステップも言いたいことわかるなあとか。
改めてState of DevOps Reportを見なければと思った。
State of DevOps Report 2021を日本語で解説 ーTeam Topologies Model、プラットフォームが重要な要素ー | TC3株式会社
まだLeanとDevOpsの科学も読めていないから早々に読み通したい。
LeanとDevOpsの科学［Accelerate］ テクノロジーの戦略的活用が組織変革を加速する impress top gearシリーズ | Nicole Forsgren Ph.D., Jez Humble, Gene Kim, 武舎広幸, 武舎るみ | 工学 | Kindleストア | Amazon https://www.amazon.co.jp/LeanとDevOpsの科学［Accelerate］-テクノロジーの戦略的活用が組織変革を加速する-impress-top-gearシリーズ-ebook/dp/B07L2R3LTN/ref=tmm_kin_swatch_0?_encoding=UTF8&qid=&sr=
次はこれ。
【CICD2021】デプロイメントパイプラインの原理原則を再確認する / Confirm Deployment Pipeline Principle - Speaker Deck
リリースに対する自信を増しながら進めていく、デプロイメントパイプライン、ということで、当たり前のような話に聞こえるけれど、それをわかりやすく解説している。
ステージとしては
- 1.コミットステージ：ユニットテストとか中心、リリース向けのコミットもこのステージで作って、あとはそれをデプロイしていく形にすることでフィードバックを早くする、5分以内に終わるようにするなど、開発者視点のテスト
- 2.受け入れステージ：エンドユーザーにとって価値のあるテストを実現できるステージにする、イメージ的にはユースケースシナリオに沿ったテストを流すような形を想定している、境界値試験などはなるべくコミットステージで対応、テストを必要以上に厚くしない、顧客視点のテスト
- 3.キャパシティステージ：一定の負荷がかかっている状態で許容可能な範囲でレスポンスを捌けているかという話、どの非機能要件が重要なのかを早期に発見する
- 4.本番
のように整理されている。（＋αあったけど資料内であまり語られていない要素もあったため割愛）
これ以外でも何度も語られているけれど、CI/CDはツールではなくプラクティス。いい言葉。
最後はこれ。
CI/CDのボトルネックを把握できていますか？BigQueryでビルド情報ダッシュボードを構築した話 - Speaker Deck
CI/CDを長期運用すると見えてくる問題として列挙されているものが今の現場に合致しすぎていて目を剥いた。
- ビルド時間がいつの間にかとても長くなっている
- ランダムにたまに失敗するビルド
- ビルドキューが詰まりがち
- ビルド・テストの失敗が放置されがちになる
これに対して、Azure Pipelinesではいつ失敗したどう失敗した、失敗したテストケースの一覧、がダッシュボードで見える。
これを他のCI/CDでも使えるようにするために、BigQueryにデータを突っ込み、それを同じGCP上のサービスであるDataStudioで可視化してる様子。
その結果、傾向把握ができ、何にどう時間がかかっているかを分析できるようになったという話で帰結。
State of DevOps ReportのCI/CDを成熟させる3つのステップの、ステージ3、拡大するの段階ではパイプラインの改善のために当然のようにメトリクスの収集・比較等々が必要なんだろうなと、別のセッションの話と繋げられて楽しかったな。
タイトルから興味あるのだけをピックアップしてみたけれど、CI/CD Conference最高だった。
ここから何を仕事に持ち込もうか、と考えるだけでワクワクするなあ。
おしまい。
Discussion