Azure DevOps umožňuje dva spôsoby, ako vytvoriť Continuous Deployment. Môžme použiť classic UI editor, alebo nový spôsob pomocou YAML súboru, kde jednotlivé kroky, job-y, stage verziujeme ako kód priamo v source control-e. Tento druhý spôsob sa nazýva Multi-Stage Pipelines. Pomocou Multi-Stage Pipelines dokážete vytvoriť proces nasadzovania od build-u, spustenia testov, nasadenia do rôznych prostredí (napríklad, Development, Staging, Production, ...) rozdelením na takzvané stages. Práve tento spôsob si ukážeme v tomto poste.
Pekny tutorial, akurat rozmyslam nad tym, aky ma zmysel mat tie YAML v source control priamo so zdrojakmi - historiu predsa robi automaticky azure portal aj bez toho, aby to bolo v zdrojakoch. Zmysel by som videl vtedy, ked robim nejaky produkt, ktory si bude kazdy buildovat a nasadzovat sam.
Problem vidim v tomto:
Co ked mam appku a vo verzii v1.0 Test a Production stage. Vo verzii v1.1 pridam este Staging stage. No a co ak potrebujem nasadit starsiu verziu 1 na Staging? Asi to ide, ale pride mi zvlastne, ze pri nasadzovani vezie v1.0 sa pouzije pipeline z vezie 1.1…
S tým čo píšeš máš pravdu. Preto v reálnom živote tieto yaml pipeline-y nemám v tom istom repe ako projekt, ale v samostatnom repe. Je to z viacerých dôvodov. Prvý je ten čo píšeš. Napríklad chcem novšou verziou pipeline-y nasadiť staršiu verziu projektu. Ďalším dôvôdom je aj to, že pokiaľ vyvíjate mikroslužby tak tých projektov / repositárov máte viacero (a nie len keď sa jedná o mikroslužby).
Čo sa týka výhod / nevýhod medzi ymal vs. classic UI to je komplikovanejšie.
Pre nás je definovanie deployment procesu as a code prehľadnejšie. Pri pozeraní zmien omnoho lepšie vidím čo sa zmenilo. Ale nič nie je jednoznačné, Classic UI je plnohodnotný CI/CD tool, ktorý má veľké množstvo výhod a predpokladám, že dlhé roky bude stále podporovaný.