dependabot運用を良い感じにする

考えてること

dependabotのPRは滞留しがち
その解決方法を模索

auto mergeは入れたいが安易に導入してしまうと環境が壊れる（動かない状態）可能性が出てくる
それは避けたい
やるなら業務時間中にだけマージする仕組みにしたい

考察

依存関係をマージする前には、必ずそれらを検証することをおすすめします。
https://docs.github.com/ja/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/upgrading-from-dependabotcom-to-github-native-dependabot#

github的には「安易にauto mergeするんじゃなくて、動作できることを確認してからマージして」っていうことを言いたいんだと思う
検証方法には「手元（＝手動）でやるか」「機械的にやるか」がある
動作検証を機械的にできれば運用コストはだいぶ減る

たぶんbest practice

CIで検証出来るようにする（機械的な検証）、その上でauto mergeの環境を作る
容易にrollback出来る仕組みも作る

i-hrm

dependabotの運用方法を模索

「dependabotの依存関係が既存の環境に影響を与えないかの検証」はしたほうが良いのは確か
- だが依存関係を確認する手段としては（分散アーキテクチャに対しては）Integration TestかE2Eぐらいしか無い気がする
- ex. aws sdkの依存関係の検証方法は限られる
Infrastructure as Code（IaC）を使用している場合、IaC自体がdeploy前でのIntegration Testをサポートしていない可能性がある
- おそらくIaCはインフラを構築するだけであって、インフラのテストができない（正しさは測れない）から
  - ex. serverless framework testing -> https://www.serverless.com/framework/docs/guides/testing
「IaCがlocalstackなどをサポート」「deploy前にtest stackを構築してそれに対してtest」が出来るならまだやり方はあるのかもしれない
IaCをしていようがしていまいがマージ前に検証が必須ならば、（現在だと）IaCとは別にIntegration Test等を行えるようにする必要がある
- これはこれでコストが大きい

結論

CIではunit testして問題なければauto merge
CD後にserverless frameworkのように確認できる手段があれば確認、問題があればRevert PRを作成するところまでを自動
外部監視を取り入れてdeploy後に問題が起きていないかを確認、問題があればRevert PRを作成するところまでを自動

i-hrm

オートマージ運用しているテックブログが出てきた

これを読む感じビルド処理があるから実現できているような気がする

Renovate によるライブラリバージョンアップブランチのビルド結果と Artifacts の URL からダウンロードしたビルド結果の差分を比較する

コンパイル言語（not スクリプト言語）やwebpackのように生成物がない場合の自動化はやはり工夫が必要そう