Ako sa zmena dostane do produkcie.

Vývoj prebieha na dvoch strojoch, ktoré sú zámerne nerovnocenné: úplné prostredie na vývojovej pracovnej stanici, kde sa nachádza databáza, a jednorazový cloudový kontajner, v ktorom sa kód píše a testuje úplne bez databázy.

Pracovná stanica phoenix-dev26.

• Riešenie sa otvára vo Visual Studio z koreňového adresára projektu a spúšťa pod Kestrel prostredníctvom spúšťacieho profilu projektu na adrese https://localhost:51880, s doplnkovým portom pre čisté HTTP, v prostredí Development.
• Aplikácia pristupuje k SQL Server priamo. Podľa rozhodnutia vlastníka pristupuje k produkčným katalógom namiesto obnovenej vývojovej kópie, pomocou pripájacieho reťazca uloženého v systémovej premennej prostredia.
• Identifikátor user secrets v projektovom súbore existuje, v praxi sa však nepoužíva; konfigurácia pochádza z prostredia.
• Jedna známa pasca: zobrazenia Razor sa kompilujú do toho istého zostavenia ako modely stránok, takže ak sa zmena v súbore .cs prejaví a zmena v súbore .cshtml nie, inkrementálne zostavenie opätovne používa zastarané zobrazenie. Riešením je odstrániť priečinky obj a bin a zostaviť riešenie znova.
• Skripty schémy spúšťa vlastník, ručne, pre každý katalóg, zo svojho vlastného klienta SQL.
• Jediný príkaz, verify.cmd, zostaví riešenie, spustí štyri sondy, spustí izolovanú inštanciu na vlastnom porte, prihlási sa, otvorí všetkých šestnásť stránok zostáv a každú stiahne ako PDF. Jeho ukážkový režim vykoná rovnaký beh nad testovacími dátami (fixtures) úplne bez databázy.

Cloudový kontajner má .NET 8 SDK, strom zostavenia a žiadnu databázu.

• Neprítomnosť pripájacieho reťazca zapína ukážkový režim, v ktorom na každý dopyt odpovedajú testovacie implementácie finančného úložiska, úložiska zostáv, kalendára, DPH a dokumentov; spúšťač odmietne štart, ak je pripájací reťazec prítomný.
• Testovacie dáta sú zostavené z vlastných dokumentov a čísel spoločnosti, takže test môže overovať voči číslam, ktoré už existujú na papieri.
• Prehliadač bez grafického rozhrania (headless) ovláda bežiacu aplikáciu na účely sond, snímok obrazovky a vykresľovania PDF.
• Lokálna náhrada odpovedá namiesto koncového bodu AI a zdrojov trhových cien a výmenných kurzov presnými pripravenými odpoveďami, takže aritmetiku možno preukázať bez účasti modelu.

Kontrolné brány. Na každé kolo sa spúšťa tridsaťsedem skriptov kontrolných brán a štyri prehliadky zdrojového kódu.

• Niektoré sú statické kontroly, ktoré overujú vlastnosť zdrojového kódu, napríklad neprítomnosť nepomenovaného stĺpca projekcie vnútri CTE alebo akéhokoľvek dlhého hexadecimálneho literálu v konfiguračnom súbore.
• Cennejšie sú tie, ktoré ovládajú bežiacu aplikáciu. Najdrahšou lekciou tohto projektu je, že test, ktorý nikdy nespustí to, čo spúšťa používateľ, nedokáže odhaliť chybu za behu.
• Kontrolné brány overujú pravidlo, ktoré kolo stanovilo, a nie výraz, ktorý bol vydaný, a pred overením odstraňujú komentáre. Túto opravu bolo treba urobiť štyrikrát samostatne.

Prenos medzi strojmi. Súbory sa prenášajú cez desktopový súborový most podľa pevného postupu:

• pred prvou úpravou v kole sa na disku pracovnej stanice vypočíta haš každého súboru, ktorého sa kolo môže dotknúť;
• pred commitom sa tie isté súbory znova pripravia a porovnajú podľa obsahu;
• po commite sa haše vypočítajú znova na oboch stranách a porovná sa súhrnný digest.

Vydané je tvrdenie o disku pracovnej stanice, nikdy o kontajneri zostavenia.

Nasadenie kopíruje na produkčný web presne štyri veci: celý priečinok so statickým webovým obsahom, aplikačné zostavenie, jeho symboly a jeho spustiteľný súbor. Konfiguračné súbory sa nekopírujú, takže produkčné nastavenia a tajomstvá vydanie prežijú. Po kopírovaní sa aplikačný fond (application pool) recykluje a kontrolný zoznam pred publikovaním vymaže token stavu (health token) a potvrdí, že diagnostická trieda bola odstránená.

Práca sa dodáva v číslovaných kolách. Aktuálne zostavenie je v31.454, čo ukazuje, ako sa projekt vedie: mnoho malých, úplných a overených dodávok namiesto dlhých vetiev. Kolo sa začína požiadavkou vlastníka, pretaví sa do matice rozhodnutí, ktoré vlastník prijme alebo zmení, a potom sa vydá celé. Kolo sa rozdelí iba pri práci, ktorú zatiaľ nemožno urobiť, napríklad pri nezodpovedanej diagnostike alebo rozhodnutí, ktoré môže urobiť iba vlastník.

Každé kolo zanechá písomný záznam.

• Poznámka ku kolu v dokumentácii projektu uvádza, čo sa zmenilo a prečo.
• Register predpokladov zaznamenáva každý úsudok, ktorý môže byť nesprávny: očíslovaný, označený v kóde vedľa riadku, ktorý riadi, ohodnotený z hľadiska rizika a doplnený SQL, ktoré by ho rozhodlo.
• Ak rozhodnutie ruší skoršie rozhodnutie, skoršie rozhodnutie sa namiesto odstránenia preškrtne a opatrí poznámkou, takže história rozhodnutia zostáva čitateľná.

Štyri trvalé pravidlá určujú, čo možno urobiť bez opýtania:

• Tajomstvá sú uložené iba v systémových premenných prostredia, nikdy v súbore, ktorý môže poskytovať webový server, a nikdy sa nevkladajú do konverzácie.
• Do projektu nemožno pridať žiadny nový balík, a preto sú implementácia Web Push, generátor PDF a parser kalendárových pozvánok napísané ručne.
• Žiadna zmena schémy vrátane nového indexu sa nevykoná bez súhlasu vlastníka a každý skript je napísaný ako chránený a opakovane spustiteľný a spúšťa ho vlastník pre každý katalóg.
• Zaúčtované účtovné údaje sa nikdy nemenia s cieľom kompenzovať problém v zobrazení a historické záznamy sa nikdy hromadne neopravujú ako vedľajší účinok opravy.

Preukazovanie je viacvrstvové.

• Zostavenie musí prebehnúť bez chýb.
• Prehliadky kontrolujú zdrojový kód na známe triedy chýb.
• Kontrolné brány overujú pravidlá.
• Sondy ovládajú bežiacu aplikáciu.
• Záverečnou kontrolou je vždy porovnanie hašov s diskom pracovnej stanice.

Ak izolované prostredie niečo nevidí, správa to uvedie. Najzreteľnejším príkladom je SQL: v kontajneri zostavenia sa nevykoná žiadny dopyt, takže zmena dopytu sa preukazuje staticky a kontrolou, kým sa nespustí na produkčných katalógoch, a správa o kole to uvádza.