Jak se změna dostane do produkce.

Vývoj probíhá na dvou strojích, které jsou úmyslně nerovnocenné: plné prostředí na vývojové pracovní stanici, kde je databáze, a jednorázový cloudový kontejner, kde se kód píše a testuje zcela bez databáze.

Pracovní stanice phoenix-dev26.

• Řešení se otevírá ve Visual Studio z kořenového adresáře projektu a spouští pod Kestrel přes spouštěcí profil projektu na https://localhost:51880, s doprovodným portem pro prosté HTTP, v prostředí Development.
• Aplikace přistupuje k SQL Server přímo. Podle rozhodnutí vlastníka přistupuje k produkčním katalogům místo obnovené vývojové kopie, přes připojovací řetězec uložený v systémové proměnné prostředí.
• V souboru projektu existuje identifikátor user secrets, v praxi se však nepoužívá; konfigurace pochází z prostředí.
• Jedna známá past: pohledy Razor se kompilují do stejného sestavení jako modely stránek, takže když se změna v souboru .cs projeví a změna v souboru .cshtml ne, inkrementální sestavení znovu používá zastaralý pohled. Nápravou je smazat složky obj a bin a sestavit znovu.
• Skripty schématu spouští vlastník, ručně, pro každý katalog zvlášť, ze svého klienta SQL.
• Jediný příkaz, verify.cmd, sestaví řešení, spustí čtyři sondy, spustí izolovanou instanci na vlastním portu, přihlásí se, otevře všech šestnáct stránek sestav a každou stáhne jako PDF. Jeho ukázkový režim provede stejný běh nad testovacími daty zcela bez databáze.

Cloudový kontejner má .NET 8 SDK, strom sestavení a žádnou databázi.

• Nepřítomnost připojovacího řetězce zvolí ukázkový režim, v němž na každý dotaz odpovídají testovací implementace finančního úložiště, úložiště sestav, kalendáře, DPH a dokladů; spouštěč odmítne start, je-li připojovací řetězec přítomen.
• Testovací data jsou sestavena z vlastních dokladů a čísel společnosti, takže test může ověřovat proti číslům, která už existují na papíře.
• Bezhlavý prohlížeč ovládá běžící aplikaci pro sondy, snímky obrazovky a vykreslování PDF.
• Místní náhrada odpovídá místo koncového bodu AI a zdrojů tržních cen a směnných kurzů přesnými předpřipravenými odpověďmi, takže aritmetiku lze prokázat bez modelu ve smyčce.

Kontrolní brány. V každém kole se spouští třicet sedm skriptů kontrolních bran a čtyři prověrky zdrojového kódu.

• Některé jsou statické kontroly, které ověřují vlastnost zdrojového kódu, například nepřítomnost nepojmenované projekce uvnitř CTE nebo jakéhokoli dlouhého hexadecimálního literálu v konfiguračním souboru.
• Cennější jsou ty, které ovládají běžící aplikaci. Nejdražší poučení tohoto projektu zní, že test, který nikdy nespustí to, co spouští uživatel, nemůže odhalit chybu za běhu.
• Kontrolní brány ověřují pravidlo, které kolo stanovilo, a ne výraz, který byl dodán, a před ověřením odstraňují komentáře; tuto opravu bylo nutné provést čtyřikrát.

Přechod mezi stroji. Soubory přecházejí přes souborový most desktopové aplikace podle pevného postupu:

• před první úpravou v kole se na disku pracovní stanice zahashuje každý soubor, kterého se kolo může dotknout;
• před commitem se tytéž soubory znovu připraví a porovnají podle obsahu;
• po commitu se obě strany znovu zahashují a porovná se souhrnný otisk.

Stav "dodáno" je tvrzení o disku pracovní stanice, nikdy o kontejneru sestavení.

Nasazení kopíruje na produkční web přesně čtyři věci: celou statickou webovou složku, sestavení aplikace, jeho symboly a jeho spustitelný soubor. Konfigurační soubory se nekopírují, takže produkční nastavení a tajemství vydání přečkají. Po kopírování se recykluje fond aplikací a kontrolní seznam před publikováním vymaže token kontroly stavu a potvrdí, že diagnostická třída byla odstraněna.

Práce se dodává v číslovaných kolech. Aktuální sestavení je v31.454, což ukazuje, jak je projekt veden: mnoho malých, úplných, ověřených dodávek místo dlouhých větví. Kolo začíná požadavkem vlastníka, převede se na matici rozhodnutí, která vlastník přijme nebo změní, a poté se dodá celé. Kolo se rozděluje pouze kvůli práci, kterou zatím nelze provést, například kvůli nezodpovězené diagnostice nebo rozhodnutí, které může učinit jen vlastník.

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

• Poznámka ke kolu v dokumentaci projektu uvádí, co se změnilo a proč.
• Registr předpokladů zaznamenává každý úsudek, který by mohl být chybný: očíslovaný, označený v kódu u řádku, kterého se týká, ohodnocený z hlediska rizika a doplněný SQL, které by jej rozhodlo.
• Pokud rozhodnutí ruší dřívější rozhodnutí, dřívější rozhodnutí se místo smazání přeškrtne a opatří poznámkou, takže historie rozhodnutí zůstává čitelná.

Čtyři trvalá pravidla určují, co lze dělat bez dotazu:

• Tajemství jsou uložena pouze v systémových proměnných prostředí, nikdy v souboru, který může webový server obsloužit, a nikdy se nevkládají do konverzace.
• Do projektu nesmí být přidán žádný nový balíček, a proto jsou implementace Web Push, generátor PDF i parser kalendářních pozvánek psány ručně.
• Žádná změna schématu, včetně nového indexu, se neprovádí bez souhlasu vlastníka a každý skript je napsán jako chráněný a opakovatelně spustitelný a spouští jej vlastník, pro každý katalog zvlášť.
• Zaúčtovaná účetní data se nikdy nemění kvůli vyrovnání problému s jejich zobrazením a historické záznamy se nikdy hromadně neopravují jako vedlejší účinek opravy.

Důkaz je vrstvený.

• Sestavení musí být čisté.
• Prověrky kontrolují zdrojový kód na známé třídy chyb.
• Kontrolní brány ověřují pravidla.
• Sondy ovládají běžící aplikaci.
• Závěrečnou kontrolou je vždy porovnání hashů s diskem pracovní stanice.

Co izolované prostředí nevidí, zpráva výslovně uvádí. Nejzřetelnějším příkladem je SQL: v kontejneru sestavení se žádný dotaz nespouští, takže změna dotazu se prokazuje staticky a kontrolou, dokud se nespustí na produkčních katalozích, a zpráva o kole to uvádí.