Preskoči na sadržaj

Zašto dva sanctioned release patterna, a ne jedan?

TL;DR

Bitbucket re-čekuje $BITBUCKET_COMMIT na početku svakog stepa, ne bilo koji commit koji je prethodni step push-ovao. Ako bump napravi novi commit i push-uje tag, a build radi u istom pipeline-u bez re-pinovanja — radi na PRE-bump commitu. Lacking CHANGELOG update + tag. Release postaje neauditabilan. Zato postoje dva sanctioned patterna, oba paze na ovo na svoj način.

Zakon

Build/deploy/notify za production release MORA raditi protiv commita koji je bump kreirao, nikad protiv pre-bump commita. Dva sanctioned patterna, oba validna, ne miješati.

Pattern 1 — Tag-triggered pipeline (klasičan)

bump pipeline (main):
  bump → ... (gura tag v1.2.3)

tag pipeline (auto-triggered by v1.2.3):
  build → scan → deploy → notify

Prednosti: potpuna separacija release i deploy; manual gate moguć; standardni CI/CD mentalni model.

Mana: treba drugi pipeline trigger (operator-fired custom: run, ili ci/git/trigger_tag_pipeline.py / ci/git/fan_out_pipeline.py).

Kada koristiti: release i deploy su namjerno decouplovani (staged approvals, manual gate, compliance).

Pattern 2 — Single-run re-checkout

bump pipeline (main):
  bump → build → scan → deploy → notify
         ↑
         make ci-checkout-release
         (svaki step počinje ovim)

Prednosti: jedan pipeline, bez fan-out; potpuno automatski.

Mana: svaki step MORA imati make ci-checkout-release prefix. Ako jedan nema — taj step radi na pre-bump commitu.

Ključni mehanizam: ci/git/checkout_release_commit.py čita ci-state.json (pipeline.release_commit + pipeline.release_mode), git fetch origin, git checkout <release_commit>, verify HEAD == release_commit. Graceful no-op ako nema release-a (artifact-only servis, non-production, no-bump run) — zato je isti prefix SIGURAN za sve stepove.

Kada koristiti: cilj je potpuni release bez manual drugog pipeline triggera.

Kada NE treba release_commit guard

  • release.enabled: false servis (artifact-only) — bump ne pravi commit ni tag, samo sjeme ci-state.json sa image_tag.
  • Non-production env (BITBUCKET_DEPLOYMENT_ENVIRONMENT != production).
  • No-bump run (npr. make <svc>-build direktno bez bump).

U sva tri slučaja pipeline.release_mode je false, release_commit nije postavljen, i ci-checkout-release je no-op. Zato je isti prefix siguran za sve stepove, ne samo production.

Anti-patterns

  • ❌ make <svc>-build bez bump u production pipeline-u — ako je bump trebao kreirati commit, nisi ga pozvao.
  • ❌ bump u pipeline-u, build u istom pipeline-u bez ci-checkout-release — build radi na pre-bump commitu.
  • ❌ Staging bump + production build — staging nema release_commit; guard mora biti production-scopan. ⚠️ ci/state.py pipeline.release_commit --strict bez production scope će failati staging run.
  • ❌ <SVC>-release-production Make target bez ci-checkout-release prefixa — generisani target to već ima; ako praviš custom, provjeri.

Vidi i