Zobrazení zdroje stránky Efektivní prostředí pro nasazování služeb

= Efektivní prostředí pro nasazování služeb=

Digitální standardy vás nutí nasazovat aktualizace služeb pravidelně, abyste:
* eliminovali pád části služeb tím, že se změní jiná část software (známé jako ‘breaking changes’),
* získali pravidelnou zpětnou vazby od uživatelů – toto pomůže navrhovat a budovat systém iterativním způsobem,
* vytvořili odolný a snadno měnitelný systém.

Cyklus uvolňování software by měl být založen na tom, jak Váš tým může podporovat aktualizace.

Některé týmy uvolňují aktualizace každý týden, jiné denně, a některé týmy uvolňují aktualizace stále během dne.

==Plnění standardu digitálních služeb==

Musíte uvolňovat aktualizace pravidelně, abyste splnili následující body:

* [[Použijte agilní metody|bod 4 (používejte agilní metody)]]
* [[Rozvíjejte a vylepšujte službu průběžně|bod 5 (rozvíjejte a vylepšujte službu průběžně)]]


==Principy pro pravidelné nasazování software==

Když nasazujete software, potřebujete:

* nasazovat často a po malých částech,
* nasazovat kvalitní software,
* provádět auditovatelné nasazování software,
* provádět pokud možno nasazování bez odstávek,
* nasazovat strojově.

===Nasazujte často a po malých částech===

Měli byste nasazovat software často a po malých částech, aby:

* uživatelé získali nové vlastnosti a zlepšení rychle místo měsíců čekání na aktualizaci,
* uživatelé mohli dříve dávat zpětnou vazbu, což pomůže postupně zlepšovat software tak, aby splňoval jejich potřeby,
* Vašemu týmu půjdou aktualizace lépe (protože je dělá často),
* identifikujete programové chyby snadněji, protože se vždy mění méně věcí najednou – to znamená, že jejich odstranění je levnější,
* můžete rychleji reagovat na urgentní opravy, jako jsou bezpečnostní aktualizace a změny na poslední chvíli,
* Váš tým může rychleji postupovat základním Lean principem [https://en.wikipedia.org/wiki/Lean_startup#Build-Measure-Learn smyčkou vytvoř (build) – vyhodnoť (measure) – pouč se (learn) - a opakuj] potřebnou pro iterativní vývoj.

Měli byste měřit, jak dlouho trvá, než se změny kódu dostanou do produkce, abyste věděli, jak pravidelný je vývojový cyklus.

===Nasazujte kvalitní software===

Abyste nasazovali kvalitní software, ujistěte se:

* nasazené verze jsou konzistentní po celém prostředí – toto Vám dá jistotu, že Vaše testování je vždy relevantní,
* automatizujte testovací proces software na rutinní kontroly hlavních funkčností.

Nasazování může být proces s malým rizikem. V době, kdy budete nasazovat novou verzi software do produkce, budete si jistí, že bude dobře fungovat.

Abyste zkontrolovali, že nová verze bude fungovat, můžete:

* nastavit <span class="underline">[https://www.gov.uk/service-manual/technology/quality-assurance-testing-your-service-regularly#how-to-test automatické test]ování</span>,
* nasadit svůj software nejdříve na definovanou řadu zkušebních serverů,
* používat [http://martinfowler.com/bliki/BlueGreenDeployment.html <span class="underline">modrozelený mechanismus nasazování</span>].

Pravidelné nasazování, které používá opakovaně a spolehlivě stejné nástroje a technologie, Vám dá jistotu, že mechanismus nasazování funguje. To proto, že stále testujete nové verze.

===Používejte auditovatelné nasazování software===

Abyste si udržovali přehled o historii verzí a měli na své verze okamžitou zpětnou vazbu, měli byste:

* vždy vědět, která verze Vašich služeb běží v každém prostředí,
* být schopni sledovat změny zpět k původnímu kódu v knihovnách zdrojových kódů poté, kdy se aktualizace dostane do produkce.

Jestliže kombinujete tento přístup s malými a častými aktualizacemi, můžete:

* zúžit zdroj jakéhokoliv problému na malý počet transakcí,
* snadněji se vrátit zpět k předchozí verzi,
* s jistotou nasazovat změnu kódu na opravu chyby v produkci – můžete si být jistější, že Vaše opravy budou fungovat, jestliže děláte časté aktualizace.

===Nasazujte nové verze bez odstávek===

Nasazování software, které minimalizuje nebo omezuje přerušení služeb je známé jako „zero downtime“ nasazování.

Toto může nastat během normálního pracovního dne, což znamená, že zaměstnanci nemusí pracovat hodiny přesčas.

Zero downtime nasazování může:

* zvýšit spokojenost uživatelů,
* snížit provozní náklady služeb – odstávky kvůli aktualizacím jsou často mimo běžnou pracovní dobu, kdy vyžadují práci provozních zaměstnanců,
* předejít problémům při naléhavých aktualizacích – například z bezpečnostních nebo kritických důvodů.

Možná si myslíte, že vytvořit aplikaci pro zero downtime nasazování představuje hodně práce, ale odstávka Vás může stát peníze. Měli byste zjistit náklady na odstávku služeb a rozhodnout se, zda můžete akceptovat tyto náklady.

Používejte kterékoliv z následujících možností pro provádění zero downtime nasazování:
[http://continuousdelivery.com/ Najděte více informací a zdrojů o nasazování software.]

===Nasazujte strojově===

Vyhněte se a co nejdříve upravte proces nasazování nových verzí SW tak, aby pro nasazení nové verze nebyl potřeba zásah člověka. Tím výrazně snížíte chybovost při nasazování, snížíte náklady provozu a snížíte závislost na konkrétních lidech a jejich aktuální dostupnosti.

==Jak nasazovat software pravidelně==

Je jednodušší nasazovat software pravidelně, jestliže:

* vytváříte jednoduchou aktualizaci spíše než varianty pro různá prostředí,
* máte více prostředí pro aktualizace,
* řídíte různé configurace,
* zabezpečujete hesla a klíče,
* používáte kontrolní testy - softwarové testy, které kontrolují, že fungují nejdůležitější funkce.
* nasazujete strojově.

===Vytváření jednoduché aktualizace===

Aktualizace může být:

* kompilovaný binární kód a z něj odvozený software,
* a .jar soubor pro jazyky JVM,
* komprimovaný archiv zdrojového kódu – bez kompilovaných částí,
* image celého virtuálního stroje s přednasazenou aplikací.

Měli byste se snažit tvořit [https://en.wikipedia.org/wiki/Artifact_%28software_development%29 <span class="underline">jednotlivé aplikace</span>], které nasadíte do každého prostředí, od vývojových serverů přes testovací po produkční.

Máte-li stejnou aktualizaci nahranou všude, znamená to:

* můžete si být jisti, že aktualizace je testována stejně, jako software v produkci,
* máte jednoduchou aktualizaci, která reprezentuje nasazení, což znamená, že je auditovatelná a je snadné ji vrátit nebo upgradovat.

Týmy rády přidávají debugging symboly, optimalizace nebo testovací kód výhradně pro předprodukční prostředí. Toto ztěžuje možnost mít jistotu o aktualizaci, která jde do produkce.

'''Organizace aktualizací'''

Měli byste uchovávat všechny aktualizace v centrálním úložišti. Pokud máte své aktualizace na jednom místě, umožní to:

* poskytnout Vašemu týmu přístup ke sdílenému souboru aktualizací,
* vylepšovat své aktualizace přes všechna prostředí,
* snadněji se vrátit k předchozímu stavu nebo aktualizovat.

Budete potřebovat mít svoje úložiště nebo si vybrat službu, kde ho budou pro Vás hostovat. Některé týmy GDS například využívají [https://www.aptly.info/ <span class="underline">Aptly</span>] nebo [https://www.sonatype.com/download-oss-sonatype <span class="underline">Nexus Repository OSS</span>].

'''Vícečetné prostředí pro nasazování'''

Můžete mít vícečetné prostředí pro nasazování, proto můžete nasazení software rozdělit do fází a zajistit, že je adekvátně testováno.

Přinejmenším potřebujete:

* vývojové prostředí, ve kterém běží poslední verze software,
* produkční prostředí s uživateli v „live“ modu.

Můžete mít také [https://www.gov.uk/service-manual/technology/working-in-pre-production-environments <span class="underline">definovanou řadu zkušebních serverů</span>] před produkcí, nebo prostředí určené pro:

* průzkumné testování,
* uživatelské testování,
* testování výkonu.

'''Používání určeného pořadí testů'''

Můžete se rozhodnout řídit vývoj svého software pro svá prostředí pomocí určeného pořadí jednotlivých prostředí.

Toto zajistí, že nová verze software není nasazena na poslední prostředí, pokud nebyla ještě nasazena a testována na předchozím stupni.

Například GOV.UK nasazuje nejdříve na svá testovací prostředí v určením pořadí, tak se může vývojový tým spolehnout, že software dělá, co má, než je nasazeno do produkce.

'''Rozhodování, do jakých prostředí nasadit software'''

Musíte se také rozhodnout, do kterých svých prostředí potřebujete nasadit aktualizaci, abyste si byli jisti funkčností produktu. Urgentní opravy mohou přeskočit nadbytečné kroky, které nejsou součástí běžného vývojového procesu a tak vývoj není zdržován.

Například produktový vlastník by neměl vyřadit bezpečnostní opravu v prostředí uživatelské akceptace.

Pořadí prostředí nemusí být striktně lineární – můžete pustit některé skupiny softwarových testů paralelně, například uživatelské akceptační testy a testy výkonnosti.

Můžete ale zjistit, že je jeden produkční bod, který je pozdější než všechny ostatní, a jeden vstupní bod, který předchází všem ostatním.

'''Řízení proměnlivých konfigurací'''

Při vytváření jednotlivé aktualizace by měl mechanismus nasazení poskytovat způsob, jak včlenit konfiguraci, která se mění v jednotlivých prostředích, jako URL odkazovaných služeb, hesla a umístění externích zařízení, například databází.

Vaše aplikace by měly dodržovat <span class="underline">[http://12factor.net/ princip 12 faktorů],</span> abyste mohli včlenit do Vašich prostředí specifické konfigurace.

'''Zabezpečení hesel a klíčů'''

Abyste zabezpečili svůj software, musíte velmi dbát na organizaci databázových hesel nebo klíčů Secure Sockets Layer (SSL). Zajistěte:

* důvěrné informace nesmí být přístupné zvenčí prostředí, pro které jsou určeny,
* důvěrné informace jsou známy pouze strojům, které je potřebují znát. Například u třívrstvé aplikace s databází, aplikací and web servery,
* databázový server nepotřebuje znát TLS (transport layer security) soukromé klíče pro stránky,
* web server nepotřebuje znát vlastnosti databáze,

'''Použití kontrolních testů po nasazení aktualizace'''

Jakmile jste nasadili software, měli byste pomocí kontrolního testu otestovat, zda pracuje, jak je očekáváno.

Jestliže aktualizace nefunguje, můžete ji zrušit nebo vrátit.

Dobrý kontrolní text by měl:

* být jednoduchý a rychlý,
* vyzkoušet software a všechny podstatné součásti systému, které může ovlivnit.

Jestliže software potřebuje databázi, aby mohl efektivně pracovat, kontrolní text by měl vyzkoušet cestu v aplikačním kódu, která selže nebo vrátí chybu, pokud databáze nebude k dispozici.

'''Když kontrolní test selže'''

Měli byste plánovat, co uděláte, pokud kontrolní text selže – nejjednodušší možností je manuálně se vrátit k předchozí verzi aplikace.

Také můžete mít systém, který automaticky najde chyby kontrolního testu a ukončí nasazení aktualizace nebo vrátí systém do stavu předchozí verze.

Ideálně systém nepřidá aktualizaci aplikace produkčnímu load balanceru, dokud nebude testována kontrolním testem a schválena (pokud aplikace selže při kontrolním testu, je vyřazena)

Toto zajišťuje, že není potřeba žádný roll back, a nedojde k žádnému přerušení služeb. Toto pracuje obzvlášť dobře s [http://martinfowler.com/bliki/ImmutableServer.html <span class="underline">neměnným systémem serveru.</span>]

'''Získejte pomoc'''

Dostaňte se do kontaktu přímo s [https://www.gov.uk/service-manual/communities/technology-community-web-operations <span class="underline">web operations community</span>], abyste:

* diskutovali tuto stránku,
* sdíleli názory napříč státní správou,
* našli podporu od týmů, které pracovaly na stejných službách.

'''Související návody'''

Může pro Vás být také užitečný návod <span class="underline">Běh systému a dostupnost</span>.