Principy vývoje

Tyto principy neříkají, jakou strukturu by měl mít váš kód, konkrétní kroky procesu nebo jak použít určité technologie - to se bude měnit v kontextu služby nebo projektu.

Tyto principy nejsou v jasném pořadí, a jsou vždy otevřené k debatě. V případě, že však půjdete vlastní cestou, očekávejte otázky.

Obecné principy

1. Veškerý kód a konfigurace je udržována v profesionálně spravovaných repositářích

Proč je to důležité

Ztráta kódu, nechtěné přepsání kódu, zmatek jaká verze kódu je správná a nemožnost opakovaně budovat aplikace, bude v budoucnu zpomalovat vývoj a bude mít dopad na kvalitu systému. Kód a konfigurace systému musí být na bezpečném místě, které musí být ostatním dostupné, aby nad tím mohli spolupracovat.

Jak to může vypadat

Jestli mít kód a config v jednom nebo více repositářích záleží na povaze služby a její vyspělosti. Repositář s kódem a configem musí splňovat následující:

jedná se centrální repositář
přístupný těm členům týmu, který přístup potřebují
v souladu se standardy bezpečnosti MSp
dostupný, když tým nebo služba potřebují
často zálohován

Kontrola

Můžete:

někomu ukázat daný repositář nebo repositáře?
vysvětlit, jak udržujete konfiguraci systému?
vysvětlit, jak často je váš kód a/nebo config zálohován?
předvést, že běžně kontrolujete kód a/nebo config, ideálně alespoň jednou za den?
někomu ukázat, kde ukládáte build skripty, deployment skripty a infrastrukturní build skripty?

2. Všechny systémy mají automatizované testy

Proč je to důležité

Dobré automatizovné testy umožňují týmu postupovat vpřed, jelikož ví, že nic nerozbil.

Jak to může vypadat

Typy testů, počet testů a co testují se může měnit na základě systému a/nebo záviset na použité technologii.

Kontrola

Můžete:

někomu automatizované testy v vašem repositáři nebo repositářích ukázat?
ukázat, že vaše testy (skoro) vždy projdou?
vysvětlit, co se stane, když se vaše testy selžou?
vysvětlit, kde testy spouštíte a ukázat výsledek předešlých testů, co jste spustili?
testy spustit teď hned?

3. Jakékoliv nasazení (deployment) aplikace je automatizovaný

Do prostředí je manualní nasazení nejen riskantní, ale i více náchylné na chyby. Zvláště ve chvílích, kdy je nasazení potřeba. Automatizované nasazení většinu těchto rizik odstraňuje.

Jak to může vypadat

Nasazování do jakéhokoliv spravovaného nebo kontrolovaného prostředí jsou automatizována pomocí nástrojů jako GitLab nebo Jenkins. Spravovaným prostředím je myšleno: produkce, pre-prod, QA, nebo systémové integrační testování. Automatizované nasazení je spuštěno buď podle kroků z předchozí build pipeliny, nebo je spuštěno manuálně. Pokud už budete s nasazením interagovat manuálně, dělejte tak co možná nejméně. Ptejte se například pouze na:

číslo buildu
cílové prostředí

Všechny jiné environment-specific informace musí přijít z místa jako je repositář nebo build job Jenkinsu.

Kontrola

Můžete:

někomu ukázat, jak nasazejte do vašeho prostředí?
sebevědomě říct, jak dlouho nasazení potrvá?
popsat, jaké nástroje používáte pro automatizované nasazování?
ukázat, kde jsou vaše deployment skripty zálohovány?

4. Systém může být vrácen zpět (roll-back) do poslední fungujícího stavu

Proč je to důležité

Pokud nasazení do spravovaného prostředí selže, služba musí přesto dál bezpečně pracovat nebo být obnovena do původní stavu co možná nejdříve. Pokud služba nefunguje, nemá hodnotu.

Jak to může vypadat

Obnovením může být automatizovaný roll-back nebo krátký popis manuálních kroků, například, vypnout aplikaci, obnovit databázi, re-deploy předchozí verzi, restartovat aplikaci. Jakýkoliv rollback musí zaručit, že data jsou obnovena do bezpečného, fungujícího stavu a že se z důvodu selhání nasazení data neztratila.

Kontrola

Můžete:

ukázat opatření, která během vývoje děláte, abyste zajistili, že při selhání nasazení můžete bezpečně udělat roll-back do předchozícho funkčního stavu?
popsat, co se stane, pokud selže nasazení do produkce?
indentifikovat, kdo autorizuje roll-back?
vysvětlit, jak byste validovali systém po roll-backu?
dokázat, že jste testovali roll-back v prostředí podobné produkci?

5. Chyby a eventy jsou loggovány tak, aby bylo možné je centrálně monitorovat

Proč je to důležité

Primární způsob, jak zjistit zdraví aplikace je skrz logy. Tyto logy by měly být v čitelném a pochopitelném formátu a měly by být odesílány na místo, kde mohou být monitorovány všemi příslušnými stakeholdery.

Jak to může vypadat

Kontrola

Můžete:

ukázat někomu poslední zápisy do logu vygenerované aplikací?
ukázat, jako jsou vaše logy monitorovány a kdo je monitoruje?
vysvětlit, co se stane, pokud je do logu zapsána chyba?

6. Architektura systému je zdokumentována

Proč je to důležité

Postupně jak se systém vyvíjí, tak vznikají a objevují se spousty informací. Tyto informace jsou podstatné jak pro stakeholdery, tak do budoucna obecně. Informace, které nelze zachytit, nelze zdokumentovat.

Jak to může vypadat

Informace o hlavních komponentách systému a jeho širší architektuře jsou zachyceny na wiki stránkách. Tyto stránky obsahují:

celkovou strukturu systému
hlavní architektonická rozhodnutí
způsoby, jak pomoc lidem se v architektuře navigovat, obsahuje i architekturu infrastruktury, architekturu nasazovaní (deployment), a proces vývoje, stejně tak i datovou strukturu

Kontrola

Můžete:

odkázat někoho na místo s wiki, kde mohu najít dokumentaci k architektuře systému?
dokázat, že je dokumentace aktuální k dnešnímu dni?