DevOps

Tip

Tento obsah je výňatek z eBooku, Architekting Cloud Native .NET Applications for Azure, který je k dispozici na webu Docs pro .NET nebo jako soubor PDF zdarma ke stažení, který si můžete přečíst offline.

Stáhnout PDF

Oblíbenou mantra softwarových konzultantů je odpovědět na otázku "Záleží" na jakékoli otázce. Není to proto, že softwarové konzultanty nemají rád pozici. Je to proto, že neexistuje žádná pravdivá odpověď na žádné otázky v softwaru. Neexistuje absolutní právo a špatná, ale spíše vyváženost mezi opaky.

Vezměte například dvě hlavní školy vývoje webových aplikací: jednostráňové aplikace (SPA) a serverové aplikace. Na jedné straně se uživatelské prostředí obvykle lépe používá u služeb SPA a množství provozu na webový server lze minimalizovat, aby bylo možné je hostovat na něčem tak jednoduchém jako statickém hostování. Na druhou stranu jsou spa obvykle pomalejší, aby se vyvinuly a obtížněji testují. Která z nich je správná volba? No, záleží na vaší situaci.

Aplikace nativní pro cloud nejsou imunní vůči té stejné dichotomie. Mají jasné výhody z hlediska rychlosti vývoje, stability a škálovatelnosti, ale jejich správa může být o něco obtížnější.

Před lety nebylo neobvyklé, že proces přesunu aplikace z vývoje do produkčního prostředí trvá měsíc nebo ještě více. Společnosti vydaly software za 6 měsíců nebo dokonce každý rok. Jeden musí hledat dál než Microsoft Windows, aby získal představu o tempu vydaných verzí, které byly přijatelné před stále zelenými dny Windows 10. Pět let uplynulo mezi Windows XP a Vista, další tři mezi Vista a Windows 7.

Je teď poměrně dobře zavedeno, že schopnost rychle vydávat software dává rychle pohyblivým společnostem obrovskou výhodu trhu oproti svým více sloth-like konkurentům. Je to proto, že hlavní aktualizace Windows 10 jsou teď přibližně každých šest měsíců.

Vzory a postupy, které umožňují rychlejší a spolehlivější vydané verze pro zajištění hodnoty pro firmu, se souhrnně označují jako DevOps. Skládají se z široké škály nápadů zahrnujících celý životní cyklus vývoje softwaru od určení aplikace až po poskytování a provoz této aplikace.

DevOps se objevila před mikroslužbami a je pravděpodobné, že přesun směrem k menším, vhodnějším účelům služeb by nebylo možné bez DevOps usnadnit vydávání a provoz nejen jedné, ale mnoha aplikací v produkčním prostředí.

Obrázek 10–1 – DevOps a mikroslužby

Díky osvědčeným postupům DevOps je možné realizovat výhody aplikací nativních pro cloud, aniž byste se museli izolovat pod horou práce, která aplikace skutečně obsluhuje.

Neexistuje žádné zlaté kladivo, pokud jde o DevOps. Nikdo nemůže prodávat kompletní a komplexní řešení pro vydávání a provoz vysoce kvalitních aplikací. Je to proto, že každá aplikace se výrazně liší od všech ostatních. Existují ale nástroje, které můžou DevOps výrazně podnítit. Jeden z těchto nástrojů se označuje jako Azure DevOps.

Azure DevOps

Azure DevOps má dlouhou pedigree. Může vysledovat kořeny zpět, když se Team Foundation Server poprvé přesunul do režimu online a prostřednictvím různých změn názvů: Visual Studio Online a Visual Studio Team Services. V letech se však stal mnohem více než jeho předchůdci.

Azure DevOps je rozdělený na pět hlavních komponent:

Obrázek 10–2 – Azure DevOps

Azure Repos – Správa zdrojového kódu, která podporuje ctihodný Správa verzí Team Foundation (TFVC) a oblíbený oborový Git. Žádosti o přijetí změn poskytují způsob, jak umožnit sociální kódování tím, že podporují diskuzi o změnách při jejich provedení.

Azure Boards – Poskytuje nástroj pro sledování problémů a pracovních položek, který se snaží uživatelům umožnit vybrat pracovní postupy, které jsou pro ně nejvhodnější. Obsahuje řadu předkonfigurovaných šablon, včetně těch, které podporují styly SCRUM a Kanbanu pro vývoj.

Azure Pipelines – Systém pro správu buildů a verzí, který podporuje úzkou integraci s Azure. Buildy je možné spouštět na různých platformách od Windows po Linux až po macOS. Agenti sestavení můžou být zřízeni v cloudu nebo místně.

Azure Test Plans – Žádná osoba pro kontrolu kvality se nezůstane pozadu díky správě testů a podpoře průzkumného testování, kterou nabízí funkce Testovací plány.

Azure Artifacts – Informační kanál artefaktů , který umožňuje společnostem vytvářet vlastní, interní verze NuGetu, npm a další. Slouží dvojímu účelu, který slouží jako mezipaměť nadřazených balíčků, pokud dojde k selhání centralizovaného úložiště.

Organizační jednotka nejvyšší úrovně v Azure DevOps se označuje jako Projekt. V rámci každého projektu je možné zapnout a vypnout různé komponenty, jako je Azure Artifacts. Každá z těchto komponent poskytuje různé výhody pro aplikace nativní pro cloud. Tři nejužitečnější jsou úložiště, panely a kanály. Pokud uživatelé chtějí spravovat zdrojový kód v jiném zásobníku úložiště, jako je GitHub, ale přesto využívají Azure Pipelines a další komponenty, je to naprosto možné.

Vývojové týmy mají naštěstí při výběru úložiště mnoho možností. Jedním z nich je GitHub.

GitHub Actions

Založena v roce 2009, GitHub je široce populární webové úložiště pro hostování projektů, dokumentace a kódu. Mnoho velkých technologických společností, jako je Apple, Amazon, Google a hlavní společnosti, používají GitHub. GitHub jako základ používá opensourcový distribuovaný systém správy verzí s názvem Git. Kromě toho přidá vlastní sadu funkcí, včetně sledování chyb, funkcí a žádostí o přijetí změn, správy úloh a wikiwebů pro každý základ kódu.

Jak se GitHub vyvíjí, přidává také funkce DevOps. GitHub má například vlastní kanál kontinuální integrace/průběžného doručování (CI/CD), který se nazývá GitHub Actions. GitHub Actions je nástroj pro automatizaci pracovních postupů založený na komunitě. Umožňuje týmům DevOps integrovat se svými stávajícími nástroji, kombinovat nové produkty a připojovat se k jejich životnímu cyklu softwaru, včetně stávajících partnerů CI/CD.

GitHub má více než 40 milionů uživatelů, což z něj dělá největšího hostitele zdrojového kódu na světě. V říjnu 2018 koupil Microsoft GitHub. Společnost Microsoft slíbila, že GitHub zůstane otevřenou platformou , ke které se může každý vývojář připojit a rozšířit. Nadále funguje jako nezávislá společnost. GitHub nabízí plány pro podnikové, týmové, profesionální a bezplatné účty.

Zdrojový ovládací prvek

Uspořádání kódu pro aplikaci nativní pro cloud může být náročné. Místo jedné obří aplikace se aplikace nativní pro cloud obvykle skládají z webu menších aplikací, které spolu komunikují. Stejně jako u všech věcí v computingu zůstává nejlepším uspořádáním kódu otevřená otázka. Existují příklady úspěšných aplikací používajících různé druhy rozložení, ale zdá se, že dvě varianty mají největší popularitu.

Než se dostanete do samotné vlastní správy zdrojového kódu, pravděpodobně stojí za to se rozhodnout, kolik projektů je vhodné. V rámci jednoho projektu existuje podpora více úložišť a kanálů sestavení. Panely jsou trochu složitější, ale úkoly je možné snadno přiřadit více týmům v rámci jednoho projektu. Z jednoho projektu Azure DevOps je možné podporovat stovky, dokonce i tisíce vývojářů. Je to pravděpodobně nejlepší přístup, protože poskytuje jediné místo, kde všichni vývojáři pracují, a snižuje nejasnosti při hledání jedné aplikace, když si vývojáři nejste jisti, ve kterém projektu se nachází.

Rozdělení kódu pro mikroslužby v rámci projektu Azure DevOps může být o něco náročnější.

Obrázek 10–3 – jeden vs. mnoho úložišť

Úložiště na mikroslužbu

Na první pohled se tento přístup jeví jako nejlogičtější přístup k rozdělení zdrojového kódu pro mikroslužby. Každé úložiště může obsahovat kód potřebný k sestavení jedné mikroslužby. Výhody tohoto přístupu jsou snadno viditelné:

1. Pokyny pro sestavení a údržbu aplikace je možné přidat do souboru README v kořenovém adresáři každého úložiště. Při procházení úložišť je snadné najít tyto pokyny a zkrátit dobu spouštění pro vývojáře.
2. Každá služba je umístěna na logickém místě, snadno nalezena tím, že zná název služby.
3. Sestavení je možné snadno nastavit tak, aby se aktivovaly jenom při změně ve vlastním úložišti.
4. Počet změn přicházejících do úložiště je omezený na malý počet vývojářů pracujících na projektu.
5. Zabezpečení je snadné nastavit omezením úložišť, na která mají vývojáři oprávnění ke čtení a zápisu.
6. Nastavení na úrovni úložiště může změnit vlastnící tým s minimální diskuzí s ostatními.

Jednou z klíčových myšlenek mikroslužeb je to, že služby by měly být oddělené a oddělené od sebe. Při použití návrhu řízeného doménou se rozhodnete o hranicích služeb, které služby fungují jako transakční hranice. Aktualizace databáze by neměly zahrnovat více služeb. Tato kolekce souvisejících dat se označuje jako ohraničený kontext. Tato myšlenka se odráží izolací dat mikroslužeb do databáze oddělené a autonomní od ostatních služeb. Má velký smysl tuto myšlenku přenést až do zdrojového kódu.

Tento přístup ale není bez problémů. Jedním z více problémů s vývojem naší doby je správa závislostí. Zvažte počet souborů, které tvoří průměrný node_modules adresář. Čerstvá instalace něčeho, jako create-react-app by s ní pravděpodobně přinesla tisíce balíčků. Otázka, jak tyto závislosti spravovat, je obtížná.

Pokud je závislost aktualizována, podřízené balíčky musí tuto závislost aktualizovat také. To bohužel trvá vývojovou práci, takže node_modules adresář končí několika verzemi jednoho balíčku, přičemž každý z nich je závislostí některého jiného balíčku, který je verze trochu jiný. Jakou verzi závislosti byste měli použít při nasazování aplikace? Verze, která je aktuálně v produkčním prostředí? Verze, která je aktuálně v beta verzi, ale pravděpodobně bude v produkčním prostředí v době, kdy ji spotřebitel provede do produkčního prostředí? Obtížné problémy, které nejsou vyřešeny pouze pomocí mikroslužeb.

Existují knihovny, na které závisí celá řada projektů. Rozdělením mikroslužeb do jednoho v každém úložišti je možné interní závislosti nejlépe vyřešit pomocí interního úložiště Azure Artifacts. Buildy pro knihovny nasdílí nejnovější verze do Azure Artifacts pro interní spotřebu. Podřízený projekt musí být stále ručně aktualizován, aby byl závislý na nově aktualizovaných balíčcích.

Další nevýhodou je přesun kódu mezi službami. I když by bylo hezké se domnívat, že první rozdělení aplikace do mikroslužeb je 100% správné, realita je, že zřídka jsme tak náchylní, aby nedošlo k chybám dělení služeb. Funkce a kód, který ho řídí, se tedy budou muset přesunout ze služby do služby: úložiště do úložiště. Při skoku z jednoho úložiště do jiného kód ztratí historii. Existuje mnoho případů, zejména v případě auditu, kdy je úplná historie části kódu neocenitelná.

Poslední a nejdůležitější nevýhodou je koordinace změn. Ve skutečné aplikaci mikroslužeb by mezi službami neměly existovat žádné závislosti nasazení. Služby A, B a C by měly být možné nasadit v libovolném pořadí, protože mají volné spojení. Ve skutečnosti však existují situace, kdy je žádoucí provést změnu, která protíná více úložišť najednou. Mezi příklady patří aktualizace knihovny tak, aby zavřela bezpečnostní díru nebo změnila komunikační protokol používaný všemi službami.

Aby bylo možné provést změnu mezi úložišti, je nutné provést potvrzení do každého úložiště po sobě. Každá změna v každém úložišti musí být požadována a zkontrolována samostatně. Tato aktivita může být obtížné koordinovat.

Alternativou k použití mnoha úložišť je dát všechny zdrojové kódy dohromady do obřího, vše vědět, jediné úložiště.

Jedno úložiště

V tomto přístupu se někdy označuje jako monorepository, veškerý zdrojový kód pro každou službu se vloží do stejného úložiště. Zpočátku se tento přístup zdá být hrozný nápad, který by pravděpodobně udělal práci se zdrojovým kódem nepraktivý. Existuje však několik výrazných výhod, které tímto způsobem fungují.

První výhodou je jednodušší spravovat závislosti mezi projekty. Místo toho, abyste se spoléhali na některé externí kanály artefaktů, můžou projekty vzájemně přímo importovat. To znamená, že aktualizace jsou okamžité a konfliktní verze budou pravděpodobně nalezeny v době kompilace na pracovní stanici vývojáře. V důsledku toho se některé z integračních testů posunou doleva.

Při přesouvání kódu mezi projekty je teď jednodušší zachovat historii, protože se soubory rozpoznají jako přesunuté a nepřepisují se.

Další výhodou je, že rozsáhlé změny, které překračují hranice služby, je možné provést v jediném potvrzení. Tato aktivita snižuje režii při potenciálně desítkách změn, které je potřeba zkontrolovat jednotlivě.

Existuje mnoho nástrojů, které můžou provádět statickou analýzu kódu pro detekci nezabezpečených programovacích postupů nebo problematického používání rozhraní API. Ve světě s více úložišti musí být každé úložiště itestrované, aby se zjistily problémy v nich. Jedno úložiště umožňuje spustit analýzu na jednom místě.

Přístup k jednomu úložišti má také mnoho nevýhod. Jednou z největších obav je, že jedno úložiště vyvolává obavy ohledně zabezpečení. Pokud dojde k úniku obsahu úložiště v úložišti na model služby, je ztráta kódu minimální. S jedním úložištěm může dojít ke ztrátě všeho, co společnost vlastní. V minulosti došlo k mnoha příkladům, které se děje, a ztěžovalo celé úsilí o vývoj her. Když máte více úložišť, zpřístupňuje méně povrchových oblastí, což je žádoucí vlastnost ve většině postupů zabezpečení.

Velikost jednoho úložiště se pravděpodobně rychle stane nespravovatelnou. To představuje několik zajímavých dopadů na výkon. Může být nutné použít specializované nástroje, jako je virtuální systém souborů pro Git, který byl původně navržen tak, aby zlepšil prostředí pro vývojáře v týmu Windows.

Argument pro použití jednoho úložiště se často omezuje na argument, který Facebook nebo Google používá pro uspořádání zdrojového kódu. Pokud je přístup pro tyto společnosti dostatečně dobrý, pak je to určitě správný přístup pro všechny společnosti. Pravdou je, že několik společností působí na čemkoli, jako je rozsah Facebooku nebo Googlu. Problémy, ke kterým dochází v těchto škálách, se liší od těch, kterým čelí většina vývojářů. Co je dobré pro husu nemusí být dobré pro gander.

Na konci je možné použít některé řešení k hostování zdrojového kódu mikroslužeb. Ve většině případů ale režijní náklady na správu a technické náklady na provoz v jednom úložišti nestojí za výhody meageru. Rozdělení kódu na více úložišť podporuje lepší oddělení obav a podporuje autonomii mezi vývojářskými týmy.

Standardní adresářová struktura

Bez ohledu na jednu a více úložišť bude mít každá služba svůj vlastní adresář. Jednou z nejlepších optimalizací, která vývojářům umožňuje rychle přecházení mezi projekty, je udržovat standardní adresářovou strukturu.

Obrázek 10-4 – standardní adresářová struktura

Při každém vytvoření nového projektu by se měla použít šablona, která umístí správnou strukturu. Tato šablona může obsahovat také takové užitečné položky jako kostra souboru README a .azure-pipelines.yml V jakékoli architektuře mikroslužeb ztěžuje vysoká míra rozptylu mezi projekty hromadné operace se službami.

Existuje mnoho nástrojů, které umožňují šablonování pro celý adresář obsahující několik adresářů zdrojového kódu. Yeoman je oblíbený ve světě JavaScriptu a GitHub nedávno vydal šablony úložiště, které poskytují většinu stejných funkcí.

Správa úkolů

Správa úkolů v jakémkoli projektu může být obtížná. Předem je potřeba odpovědět na otázky týkající se druhu pracovních postupů, které se mají nastavit, aby se zajistila optimální produktivita vývojářů.

Nativní cloudové aplikace mají tendenci být menší než tradiční softwarové produkty nebo jsou aspoň rozdělené do menších služeb. Sledování problémů nebo úkolů souvisejících s těmito službami zůstává stejně důležité jako u jakéhokoli jiného softwarového projektu. Nikdo nechce ztratit přehled o nějaké pracovní položce nebo vysvětlit zákazníkovi, že jeho problém nebyl správně protokolován. Panely se konfigurují na úrovni projektu, ale v rámci každého projektu je možné definovat oblasti. To umožňuje rozdělit problémy napříč několika komponentami. Výhodou zachování veškeré práce pro celou aplikaci na jednom místě je, že je snadné přesouvat pracovní položky z jednoho týmu do jiného, jak jsou pochopeny lépe.

Azure DevOps obsahuje řadu předkonfigurovaných oblíbených šablon. V nejzásadnější konfiguraci je potřeba vědět, co je v backlogu, na čem lidé pracují, a co se dělá. Je důležité mít tento přehled o procesu sestavování softwaru, aby bylo možné určit prioritu a dokončené úkoly nahlášené zákazníkovi. Samozřejmě, několik softwarových projektů se drží procesu stejně jednoduché jako to do, doinga done. Než lidé začnou přidávat kroky jako QA nebo Detailed Specification do procesu, trvá to dlouho.

Jednou z důležitějších částí agilních metodologií je samoobslužná introspekce v pravidelnýchintervalech Tyto recenze mají poskytnout přehled o problémech, kterým tým čelí, a o tom, jak je možné je vylepšit. Často to znamená změnu toku problémů a funkcí prostřednictvím procesu vývoje. Takže je dokonale v pořádku rozšířit rozložení desek o další fáze.

Fáze na panelech nejsou jediným nástrojem organizace. V závislosti na konfiguraci panelu existuje hierarchie pracovních položek. Nejpodrobnější položka, která se může objevit na panelu, je úkol. Úkol obsahuje pole pro název, popis, prioritu, odhad zbývající práce a možnost propojení s jinými pracovními položkami nebo vývojářskými položkami (větve, potvrzení, žádosti o přijetí změn, sestavení atd.). Pracovní položky je možné klasifikovat do různých oblastí aplikace a různých iterací (sprintů), aby bylo hledání jednodušší.

Obrázek 10–5 – Úloha v Azure DevOps

Pole popisu podporuje normální styly, které byste očekávali (tučné písmo, kurzíva a přeškrtnutí) a možnost vkládat obrázky. Díky tomu je výkonný nástroj pro použití při zadávání práce nebo chyb.

Úkoly je možné zahrnovat do funkcí, které definují větší jednotku práce. Funkce lze postupně zahrnovat do námětů. Klasifikace úkolů v této hierarchii usnadňuje pochopení toho, jak blízko velké funkce je zavádění.

Obrázek 10–6 – Pracovní položka v Azure DevOps

V Azure Boards existují různé druhy zobrazení problémů. Položky, které ještě nejsou naplánované, se zobrazí v backlogu. Odtud je možné je přiřadit ke sprintu. Sprint je časové pole, během kterého se očekává, že se dokončí určité množství práce. Tato práce může zahrnovat úkoly, ale také řešení lístků. Jakmile tam bude celý sprint, můžete ho spravovat v části Panel sprintů. V tomto zobrazení se dozvíte, jak práce probíhá, a obsahuje graf burn down, abyste mohli odhadnout, jestli bude sprint úspěšný.

Obrázek 10–7 – Panel v Azure DevOps

Prozatím by mělo být zřejmé, že v Boards v Azure DevOps existuje velký výkon. Pro vývojáře existují jednoduchá zobrazení toho, na čem se pracuje. Pro projektové manažery si můžete prohlédnout nadcházející práci a přehled stávajících prací. Pro manažery existuje spousta sestav o obnovení a kapacitě. Bohužel není nic magického o aplikacích nativních pro cloud, které eliminují potřebu sledovat práci. Pokud ale potřebujete sledovat práci, existuje několik míst, kde je prostředí lepší než v Azure DevOps.

Kanály CI/CD

Téměř žádná změna životního cyklu vývoje softwaru byla tak revoluční jako nástup kontinuální integrace (CI) a průběžného doručování (CD). Vytváření a spouštění automatizovaných testů na zdrojovém kódu projektu, jakmile se změna zkontroluje, zachytává chyby včas. Před nástupem buildů kontinuální integrace by nebylo neobvyklé načíst kód z úložiště a zjistit, že neprošel testy nebo se ani nedal sestavit. Výsledkem bylo sledování zdroje přerušení.

Tradičně expediční software do produkčního prostředí vyžadoval rozsáhlou dokumentaci a seznam kroků. Každý z těchto kroků je potřeba provést ručně ve velmi náchylné chybě procesu.

Obrázek 10-8 – kontrolní seznam

Sestra kontinuální integrace je průběžné doručování, ve kterém se do prostředí nasazují nově vytvořené balíčky. Ruční proces nemůže škálovat tak, aby odpovídal rychlosti vývoje, takže automatizace je důležitější. Kontrolní seznamy jsou nahrazeny skripty, které mohou provádět stejné úlohy rychleji a přesněji než jakýkoli člověk.

Prostředí, do kterého průběžné doručování doručuje, může být testovacím prostředím nebo, jak to dělá mnoho velkých technologických společností, může se jednat o produkční prostředí. Druhá vyžaduje investici do vysoce kvalitních testů, které můžou dát jistotu, že změna nebude pro uživatele přerušovat produkci. Stejným způsobem, jakým kontinuální integrace chytila problémy v kódu v rané fázi průběžného doručování, zachytává problémy v procesu nasazení včas.

Důležitost automatizace procesu sestavení a doručování je zvýrazněná aplikacemi nativními pro cloud. Nasazení probíhají častěji a více prostředí, takže ručně nasazuje hranice na nemožné.

Azure Builds

Azure DevOps poskytuje sadu nástrojů, které usnadňují kontinuální integraci a nasazování, než kdy dřív. Tyto nástroje jsou umístěné ve službě Azure Pipelines. První z nich je Azure Builds, což je nástroj pro spouštění definic sestavení založených na YAML ve velkém měřítku. Uživatelé můžou používat vlastní počítače sestavení (skvělé pro to, pokud sestavení vyžaduje pečlivě nastavené prostředí), nebo použít počítač z neustále aktualizovaného fondu virtuálních počítačů hostovaných v Azure. Tito hostovaní agenti sestavení jsou předinstalovaní s širokou škálou vývojových nástrojů pro vývoj nejen pro .NET, ale pro všechno od Javy až po Python až po vývoj i Telefon.

DevOps zahrnuje širokou škálu předestavovaných definic sestavení, které je možné přizpůsobit pro jakékoli sestavení. Definice sestavení jsou definovány ve volaném azure-pipelines.yml souboru a vráceny se změnami do úložiště, aby je bylo možné upravovat verze společně se zdrojovým kódem. To usnadňuje provádění změn kanálu buildu ve větvi, protože se změny dají vrátit se změnami jenom do této větve. Příklad azure-pipelines.yml vytvoření webové aplikace ASP.NET v plné architektuře je znázorněn na obrázku 10–9.

name: $(rev:r)

variables:
  version: 9.2.0.$(Build.BuildNumber)
  solution: Portals.sln
  artifactName: drop
  buildPlatform: any cpu
  buildConfiguration: release

pool:
  name: Hosted VisualStudio
  demands:
  - msbuild
  - visualstudio
  - vstest

steps:
- task: NuGetToolInstaller@0
  displayName: 'Use NuGet 4.4.1'
  inputs:
    versionSpec: 4.4.1

- task: NuGetCommand@2
  displayName: 'NuGet restore'
  inputs:
    restoreSolution: '$(solution)'

- task: VSBuild@1
  displayName: 'Build solution'
  inputs:
    solution: '$(solution)'
    msbuildArgs: '-p:DeployOnBuild=true -p:WebPublishMethod=Package -p:PackageAsSingleFile=true -p:SkipInvalidConfigurations=true -p:PackageLocation="$(build.artifactstagingdirectory)\\"'
    platform: '$(buildPlatform)'
    configuration: '$(buildConfiguration)'

- task: VSTest@2
  displayName: 'Test Assemblies'
  inputs:
    testAssemblyVer2: |
     **\$(buildConfiguration)\**\*test*.dll
     !**\obj\**
     !**\*testadapter.dll
    platform: '$(buildPlatform)'
    configuration: '$(buildConfiguration)'

- task: CopyFiles@2
  displayName: 'Copy UI Test Files to: $(build.artifactstagingdirectory)'
  inputs:
    SourceFolder: UITests
    TargetFolder: '$(build.artifactstagingdirectory)/uitests'

- task: PublishBuildArtifacts@1
  displayName: 'Publish Artifact'
  inputs:
    PathtoPublish: '$(build.artifactstagingdirectory)'
    ArtifactName: '$(artifactName)'
  condition: succeededOrFailed()

Obrázek 10–9 – ukázka azure-pipelines.yml

Tato definice sestavení používá řadu předdefinovaných úkolů, díky kterým je vytváření sestavení stejně jednoduché jako sestavení sady Lego (jednodušší než obří Millennium Falcon). Například úloha NuGet obnoví balíčky NuGet, zatímco úloha VSBuild volá nástroje sestavení sady Visual Studio k provedení skutečné kompilace. V Azure DevOps jsou k dispozici stovky různých úloh s tisíci dalších úloh, které spravuje komunita. Je pravděpodobné, že bez ohledu na to, jaké úkoly sestavení chcete spustit, někdo už ho vytvořil.

Sestavení se dají aktivovat ručně, a to vrácením se změnami, podle plánu nebo dokončením jiného sestavení. Ve většině případů je žádoucí stavět na každém check-inu. Sestavení je možné filtrovat tak, aby se různá sestavení spouštěla na různých částech úložiště nebo v různých větvích. To umožňuje scénáře, jako je spouštění rychlých buildů s omezeným testováním na žádostech o přijetí změn a spouštění úplné regresní sady pro kmen na noční bázi.

Konečným výsledkem sestavení je kolekce souborů označovaných jako artefakty sestavení. Tyto artefakty je možné předat dalšímu kroku procesu sestavení nebo přidat do informačního kanálu Azure Artifacts, aby je mohly využívat další sestavení.

Verze Azure DevOps

Sestavení se postará o kompilaci softwaru do expedovatelného balíčku, ale artefakty je potřeba odeslat do testovacího prostředí, aby bylo možné průběžné doručování dokončit. V tomto případě Azure DevOps používá samostatný nástroj s názvem Vydané verze. Nástroj Release využívá knihovnu stejných úloh, která byla k dispozici pro sestavení, ale představuje koncept "fází". Fáze je izolované prostředí, do kterého je balíček nainstalován. Například produkt může využívat vývoj, kontrolu kvality a produkční prostředí. Kód se nepřetržitě dodává do vývojového prostředí, ve kterém je možné spouštět automatizované testy. Jakmile tyto testy projdou vydáním, přejde do prostředí pro kontrolu kvality pro ruční testování. Nakonec se kód nasdílí do produkčního prostředí, kde je viditelný všem.

Obrázek 10–10 – kanál verze

Každou fázi sestavení je možné automaticky aktivovat dokončením předchozí fáze. V mnoha případech to ale není žádoucí. Přesunutí kódu do produkčního prostředí může vyžadovat schválení od někoho. Nástroj Release to podporuje povolením schvalovatelů v každém kroku kanálu verze. Pravidla je možné nastavit tak, aby se určitá osoba nebo skupina lidí před uvedením do produkčního prostředí musely odhlásit k vydání verze. Tato hradla umožňují ruční kontroly kvality a také dodržování jakýchkoli zákonných požadavků souvisejících s kontrolou toho, co se děje v produkčním prostředí.

Všichni získají kanál buildu.

Konfigurace mnoha kanálů sestavení není nijak nákladná, takže je výhodné mít alespoň jeden kanál buildu na mikroslužbu. V ideálním případě jsou mikroslužby nezávisle nasazovatelné do libovolného prostředí, takže každá z nich může být uvolněna prostřednictvím vlastního kanálu, aniž by uvolnila množství nesouvisejícího kódu, je perfektní. Každý kanál může mít vlastní sadu schválení, která umožňují varianty procesu sestavení pro každou službu.

Verze správy verzí

Jednou z nevýhod používání funkcí Vydané verze je, že není možné ji definovat v vrácených souborech azure-pipelines.yml . Existuje mnoho důvodů, proč byste to mohli chtít udělat– od definic vydané verze pro jednotlivé větve až po zahrnutí kostry vydané verze do šablony projektu. Naštěstí se pracuje na tom, aby se některé fáze podpory přesunuly do komponenty Sestavení. To se bude považovat za vícefázové sestavení a první verze je teď k dispozici!

PředchozíDalší