Skip to main content

Bilko support repo split — plan (2026-08-23)

MC #900161 — Plan: izdvajanje bilko.cloud support surface u novi AzDO repo

CEO nalog: "kao sto smo izvukli image, container treba src code i pipeline izvuci — dva projekta main/support." Ovo je PLAN, ne implementacija. Čeka CEO odobrenje prije bilo kakvog reza u kodu ili pipeline-u.

1. Cilj

Nezavisan support lifecycle: deploy supporta ne čeka main CI, main incident ne blokira support fix. Čišća RBAC/blast-radius granica — support je admin-only povrsina, danas dijeli sliku i deploy rizik s main-om. Krajnji rezultat: support.bilko.cloud servira se iz vlastitog repoa/pipeline-a/slike, main repo ostaje netaknut.

2. Stanje danas (izvor: scout-pipeline.md, scout-code.md)

  • Support nema vlastiti build/scan: jaše na main-ovom build_demo_web jobu (azure-pipelines.yml:2166-2195), ista apps/web/Dockerfile, isti tag bilko-web:demo-$(SHORT_SHA), isti ACR bilkodemo.azurecr.io.
  • Deploy je jedini support-specifičan korak: 2. az containerapp update (2309-2320) na bilko-web-support-demo, postavlja BILKO_APP_SURFACE=support kao runtime env var (nije build ARG — ista slika, dva poda).
  • Verify: 3 curl provjere (2376-2408): /admin→307, /dashboard→404, /invoices→404 na support.bilko.cloud.
  • Kod: 8 support-only fajlova pod app/(admin)/admin/*, 12 dijeljenih auth fajlova (8 lib + 4 stranice), 6 backend endpointa pod /admin/* namespace-om, 30 testova u app-surface-900075.test.ts. Ukupno ~35-40 fajlova za novi repo (scout-code.md summary tabela).
  • Support postoji SAMO na demo tier-u — nula footprint u CI_Gates/Build/Deploy_Stage/E2E_UAT/Write_UAT.

3. Odluka za CEO #1 — isti AzDO projekat (novi repo) vs novi AzDO projekat

Kelsey (pipeline scout) preporučuje: novi REPO u postojećem Bilko projektu, ne novi projekat.

  • Agent pool (bilko-selfhosted, 1 org-wide CI slot) je org-level resurs — dijeli se identično bez obzira na odluku.
  • Service connection azure-bilko i variable group bilko-kv-demo (Key Vault-linked) su project-scoped po defaultu. Novi projekat = ponovno kreiranje/grant SP permisija i dupliranje variable grupa. Novi repo u istom projektu nasljeđuje sve to plus postojeći Promote_Demo environment approval gate, bez dodatnog AzDO admin posla. Pitanje za CEO-a: kad kažeš "dva projekta", misliš li na RBAC/board izolaciju (support tim ne vidi main backlog/work items) ili na tehničku separaciju build/deploy lanaca? Ako je prvo — novi projekat ima smisla uprkos trošku re-provisioninga. Ako je drugo (isporuka/rizik razdvojeni) — repo u istom projektu postiže isti tehnički cilj bez ponovnog AzDO admin rada. Moja preporuka: repo u istom projektu, osim ako je RBAC izolacija eksplicitan zahtjev — tehnički cilj (nezavisan lifecycle) se postiže repoom i pipeline-om, ne granicom projekta.

4. Odluka za CEO #2 — dijeljeni auth kod (12 fajlova) i API klijent

Dvije opcije: (a) git subtree pull pinovan na main-ov SHA, ponovna sinhronizacija ručnim korakom; (b) zajednički npm paket (interni registry/workspace), verzionisan i publikovan. Kelsey upozorava: "pin, ne copy-paste, protiv tihog drifta" — čisti copy-paste bez pina je isti obrazac koji je već izazvao tihi drift na drugim mjestima (RS mali preduzetnik, HR kontni plan — vidi memoriju). Moja preporuka za mali tim (1 čovjek + AI agenti održava oba repoa): git subtree, pinovan na eksplicitan main SHA, dokumentovan ručni resync postupak. Zajednički paket je arhitektonski čišći dugoročno, ali dodaje publish pipeline + registry — novi CI surface koji troši isti org-wide slot i nije opravdan za 12 fajlova koji se rijetko mijenjaju (MSAL/auth integracija je stabilna, ne sedmični churn). Eksplicitan SHA pin čini drift vidljivim i revizibilnim umjesto nevidljivim.

5. Faze

F1 — novi repo + pipeline skeleton + fork slike + paralelni test pod (main repo se NE dira)

  1. Kreirati novi AzDO repo (bilko-web-support) u Bilko projektu (per odluka #1).
  2. Skeleton azure-pipelines.yml: stage Build_Scan — vlastiti Dockerfile, build+push bilko-web-support:$(SHORT_SHA) u isti ACR.
  3. Registrovati/ponovo iskoristiti SC_AZURE service connection, ACR push pristup, variable group (slimana bilko-kv-demo podskupina).
  4. Vlastiti Trivy image scan (HIGH,CRITICAL) — danas se "vozi" na main-ovom skenu iste slike, ta pokrivenost nestaje čim se slika forkuje ako se ne duplira.
  5. Stage Deploy_Support_Demo: deploy na NOVI test ACA pod (bilko-web-support-demo-v2) — postojeći bilko-web-support-demo ostaje netaknut.
  6. Stage Verify: 3 PI2-ekvivalentne provjere protiv v2-ovog direktnog ACA FQDN-a (ne custom domain).
  7. Potvrda: main repo azure-pipelines.yml diff = 0 linija. Trajanje: 6-10h agentskog rada (pipeline skeleton, AzDO wiring, paralelni pod, verify). Izlazni kriterij: v2 pod ispravno odgovara na 3 provjere na direktnom FQDN-u, scan prolazi, main pipeline netaknut.

F2 (tek poslije CEO odobrenja) — src ekstrakcija + testovi + cutover

  1. Ekstrakcija 8 support-only fajlova (app/(admin)/admin/*).
  2. Ekstrakcija/subtree-pin dijeljenog auth sloja (12 fajlova) na izabran main SHA (odluka #2).
  3. Ekstrakcija core mehanizma: app-surface.ts, middleware.ts.
  4. Migracija lib/api.ts admin metoda (6 endpointa: listOrgs, getOrg, patchOrg, listOrgUsers, impersonate, endImpersonation).
  5. Migracija/adaptacija app-surface-900075.test.ts (30 testova) u CI novog repoa; odlučiti da li ostaje i u main repou (boundary logika za / ostaje relevantna glavnoj aplikaciji do F3).
  6. Ožičenje env varijabli (7 NEXT_PUBLIC_* + BILKO_APP_SURFACE=support kao ACA runtime env, ne build ARG).
  7. Cutover: repoint custom-domain binding support.bilko.cloud → v2 target (isti managed-cert obrazac kao MC #105793) — DNS se ne dira, samo ingress binding target.
  8. Soak prozor na starom podu (ostaje živ, ne briše se) — rollback = repoint binding nazad, bez rebuilda. Trajanje: 14-20h agentskog rada (najveći komad: paritet testova + potvrda da platformAdmin JWT i dalje radi kroz novi build). Izlazni kriterij: support.bilko.cloud servira novi pod, 3 PI2 provjere + 30 testova zeleni na novom repou, soak prozor (preporuka 48-72h) prošao bez incidenta, stari pod i dalje živ.

F3 (tek poslije F2 soak-a) — čišćenje main repoa

  1. Ukloniti support deploy/verify blokove iz azure-pipelines.yml (2309-2320, 2376-2408).
  2. Ugasiti stari bilko-web-support-demo pod.
  3. Ukloniti support-only kod iz apps/web (app/(admin)/*, BILKO_APP_SURFACE gating) nakon potvrde da main više ne referencira.
  4. Odlučiti sudbinu app-surface-900075.test.ts u main CI (zadržati ako main i dalje ima admin-adjacent putanje koje test pokriva).
  5. Ažurirati BookStack runbook stranice koje referenciraju support deploy u main pipeline-u. Trajanje: 3-5h. Izlazni kriterij: main azure-pipelines.yml ima nula support-specifičnih koraka, CI runtime main-a nepromijenjen.

6. Rizici i rollback

  1. Entra redirectUri: NEXT_PUBLIC_ENTRA_REDIRECT_URI nije postavljen ni danas — obje površine koriste bare-origin fallback; support.bilko.cloud mora ostati u allowlisti, guard mora dozvoliti auth povratne putanje (memorija: surface guard mora dozvoliti auth redirect). Provjeriti na v2 test podu PRIJE cutovera.
  2. Image drift vs main API kontrakt: nakon forka slike, support repo mora pinovati API kontrakt (docs/backend/API-REFERENCE.md ili OpenAPI artefakt) na main-API SHA — ne ručno kopirati, inače tihi drift.
  3. 1 CI slot je org-wide bez obzira na odluku #1; novi pipeline NE smije otimati slot main-u — isti trigger obrazac kao main (branch-scoped, ne svaki commit/PR).
  4. Trivy scan pokrivenost nestaje čim se slika forkuje ako F1 korak 4 nije tvrd izlazni kriterij, ne "nice to have".
  5. Rollback mreža postoji SAMO dok stari pod živi — ako se F3 (brisanje starog poda + čišćenje main pipeline-a) izvede prije nego soak prozor iz F2 prođe, nema mreže za povratak.

7. Šta se ne dira

  • azure-pipelines.yml u main repou (nula izmjena do F2 koraka 7 / F3).
  • Service connections, ACR, variable group bilko-kv-demo, DNS zapis za support.bilko.cloud (mijenja se samo ingress binding target u F2 koraku 7, ne sam DNS zapis).
  • Izvorni kod u apps/web monorepou ostaje nepromijenjen do F2/F3 ekstrakcije.

8. Procjena

Faza Sati agentskog rada Šta CEO mora obezbijediti
F1 6-10h Odluka #1 i #2 prije starta; ako odluka #1 = novi projekat, treba org-admin za kreiranje projekta (agent nema tu permisiju)
F2 14-20h Odobrenje plana (ovaj dokument) prije starta; ako odluka #1 = novi projekat, ponovni grant SP/service connection permisija
F3 3-5h Odobrenje da je soak prozor (48-72h) prošao
Ukupno: ~23-35h agentskog rada kroz sve tri faze, plus jedan ili dva administrativna CEO koraka (odluke #1/#2, eventualno AzDO project-create permisija ako se bira novi projekat).

AFTER — F1 isporučen 2026-08-24 (MC #900162)

Repo Bilko-Support kreiran ručno (CEO, 24.08.) nakon PAT 401 blokade od 23.08. F1 koraci 2-7 isporučeni i nezavisno verifikovani:

  • Pipeline skeleton na origin/main (commit a4e0662): trigger samo main, pr none, bez schedules, Build_Scan gated-off do F2, Trivy uvijek on, Deploy_Support_Demo + Verify protiv v2.
  • Fork slike: az acr import → bilko-web-support:demo-1d58cbb6, digest bajt-identičan izvoru (sha256:f1002bd2...0178f).
  • Trivy (FORGE): 0 HIGH/CRITICAL, exit 0.
  • Novi test pod bilko-web-support-demo-v2 Running, samo direktni ACA FQDN; verify 3/3 (/admin→307, /dashboard→404, /invoices→404).
  • Main repo i stari pod netaknuti (git status baseline + lastModifiedAt identičan; customDomains nepromijenjen).
  • Peer-verify (writer≠verifier): verifier-900162, Verdict PASS/VERIFIED — /Users/makinja/system/evidence/900162/peer-verify-transcript-20260824.md
  • Builder evidence: /Users/makinja/system/evidence/900162/resume-report-20260824.md

Otvoreno za F2: registracija AzDO pipeline definition objekta (yml dormantan do tada); repo-id diskrepanca (c50cad02 vs c170e706) zapisana.

No comments to display

Back to top