Columbia Games · CCM v2 / 2026. augusztus 26.
A legutóbbi deploy nem feltétlenül a legutóbbi jó deploy
A change detection és recovery korábban túl könnyen tekintett egy megpróbált production SHA-t jó alapnak. Ezt a last successful runtime SHA fogalmával kellett helyretenni.
A helyzet
Ha egy deployment félúton vagy post-deploy QA alatt elbukik, a commit ettől még megjelent a deployment történetben. Ha a következő futás ezt használja összehasonlítási alapnak, azt hiheti, hogy bizonyos változások már productionban vannak, pedig sosem validáltuk őket. Ugyanez recoverynél még veszélyesebb.
A megoldási út
Külön tároltuk a last successful runtime SHA-t, és csak sikeres, ellenőrzött release után frissítettük. A change detection ehhez viszonyított, nem az utolsó attempted commithoz. Kifejezetten megtiltottam, hogy egy unverified production SHA automatikusan „good” állapotot kapjon.
Mi lett belőle
Egy sikertelen deploy után a következő futás továbbra is a valóban aktív, bizonyított runtime-ból számolta a változásokat. A recovery és incremental deploy ugyanarról a valós állapotról beszélt.