Sdílet prostřednictvím

Vývojový životní cyklus

  • Článek

Strategie životního cyklu vývoje poskytuje klíčové aspekty návrhu a doporučení pro úložiště, větev, automatizované sestavení, nasazení a vrácení zpět během automatického vytváření cílové zóny.

Strategie úložiště

Aspekty návrhu

  • Zvažte přijetí systému správy verzí, jako je Git, který vašemu týmu poskytuje flexibilitu při sdílení a správě kódu.

    • Git je standardní systém správy verzí. Jedná se o distribuovaný systém správy verzí, kde vaše místní kopie kódu představuje úplnou verzi úložiště.

  • Seznamte se s mono-úložištěm a strukturou úložiště multirepo.

    • V mono-úložištích se veškerý zdrojový kód nachází v jednom úložišti.
    • Ve vícerepo strukturách jsou všechny projekty uspořádány do samostatných úložišť.

  • Zvolte nastavení viditelnosti, které odpovídá obsahu úložiště.

    • K veřejným úložištím je možné přistupovat anonymně.
    • Privátní úložiště vyžadují, aby měli uživatelé udělený přístup k úložišti a přihlásili se ke službám.
    • Pro azure DevOps Projects a úložiště GitHub můžete nastavit veřejnou a soukromou viditelnost.

  • Zvažte nastavení oprávnění úložiště, která vám pomůžou řídit, kdo může přispívat do zdrojového kódu a spravovat další funkce.

  • Zvažte použití nasazení prostředků Infrastruktury jako kódu (IaC) do Azure. IaC umožňuje spravovat infrastrukturu v deklarativním modelu, což pomáhá snížit úsilí o konfiguraci, zajistit konzistenci mezi nasazeními a vyhnout se ruční konfiguraci prostředí.

  • Azure poskytuje podporu IaC pro cílové zóny prostřednictvím:

Doporučení k návrhu

  • Git použijte jako systém správy verzí.

  • Použití privátních úložišť při sestavování cílových zón Azure

  • Při sdílení nekonfidentiálních informací, jako jsou příklady automatizace, veřejná dokumentace a materiály pro opensourcovou spolupráci, používejte veřejná úložiště.

  • Osvojte si přístup IaC pro nasazování, správu, řízení a podporu cloudových prostředků.

Strategie větve

Aspekty návrhu

  • Zvažte použití strategie větve, která týmům umožňuje lépe spolupracovat a efektivně spravovat správu verzí.

  • Zvažte použití konkrétních konvencí vytváření názvů pro vaše větve.

  • Zvažte použití oprávnění větve k řízení uživatelských možností.

  • Zvažte použití zásad větví, které pomáhají týmům chránit důležité větve vývoje. Zásady, které můžou pomoct vynucovat standardy kvality kódu a správy změn Mezi příklady zásad větví patří:

  • Přijetí strategie žádosti o přijetí změn vám může pomoct udržet kontrolu nad změnami kódu sloučené do větví.

    • Definujte strategii sloučení.
    • Žádosti o přijetí změn by měly být jednoduché, protože počet souborů se uchovává na minimum, aby kontroloři mohli ověřovat potvrzení a změny efektivněji.
    • Žádosti o přijetí změn by měly mít jasné názvy a popisy, aby revidující věděli, co mají očekávat při kontrole kódu.
    • Můžete použít šablony žádostí o přijetí změn.
    • Po dokončení žádostí o přijetí změn můžete odstranit větve původu, což vám dává větší kontrolu a lepší správu větví.

Doporučení k návrhu

  • Osvojte si vývojový model založený na kmenech, ve kterém se vývojáři zaváže do jedné větve. Tento model usnadňuje kontinuální integraci. Veškerá práce funkce se provádí v kufru a všechny konflikty při slučování se vyřeší, když se potvrzení stane.

  • Požádejte své týmy, aby definovaly a používaly konzistentní zásady vytváření názvů pro větve k identifikaci provedené práce.

  • Nastavte oprávnění pro řízení, kdo může číst a aktualizovat kód ve větvi vašeho úložiště Git. Můžete nastavit oprávnění pro jednotlivé uživatele a skupiny.

  • Nastavení zásad větve:

    • Vyžadovat použití žádostí o přijetí změn pro větev se sloučí do hlavní větve.
    • Vyžaduje minimální počet revidujících pro žádosti o přijetí změn.
    • Resetováním všech schvalovacích hlasů odeberete všechny schvalovací hlasy, ale hlasy můžete odmítnout nebo počkat, kdykoli se změní zdrojová větev.
    • Automaticky zahrnout revidujícím kód.
    • Zkontrolujte rozlišení komentářů.

  • Nastavte squash jako strategii sloučení, která umožňuje kondenzovat historii témat větví Gitu při dokončování žádostí o přijetí změn. Místo přidání každého potvrzení do větve tématu do historie výchozí větve přidá squash merge všechny změny souboru do jediného nového potvrzení ve výchozí větvi.

Automatizované buildy

Aspekty návrhu

  • Zvažte implementaci kontinuální integrace (CI). Ci zahrnuje sloučení veškerého vývojářského kódu do centrálního základu kódu v pravidelném plánu a automatické spouštění standardních sestavení a testovacích procesů.

  • Zvažte použití triggerů CI:

    • Git Azure Repos Větve, cesty a značky můžete nakonfigurovat jako triggery pro spuštění sestavení CI.
    • GitHub. Ke spuštění sestavení CI můžete nakonfigurovat větve, cesty a triggery značek.

  • Zvažte zahrnutí testů jednotek IaC do procesu sestavení za účelem ověření syntaxe.

    • Testovací sada nástrojů pro šablony ARM kontroluje, jestli šablona dodržuje doporučené postupy.
    • Bicep linter kontroluje chyby syntaxe a porušení osvědčených postupů v souborech Bicep.

  • Zvažte zahrnutí testů jednotek do procesu sestavení aplikace. Projděte si úlohy dostupné pro Azure DevOps Pipeline.

  • Ke správě připojení k Azure ke správě připojení k Azure použijte připojení ke službě Azure DevOps nebo tajné kódy GitHubu. Každé připojení by mělo mít správný přístup k prostředkům Azure.

  • Zvažte použití tajných kódů služby Azure Key Vault k ukládání a správě citlivých informací, jako jsou hesla, klíče rozhraní API nebo certifikáty.

  • Agenti Azure DevOps můžou být hostovaní sami nebo Microsoft.

    • Údržba a upgrady se za vás postará, když používáte agenty hostované Microsoftem. Při každém spuštění úlohy sestavení se vytvoří nový virtuální počítač.
    • Agenty v místním prostředí můžete nastavit a spravovat sami, abyste mohli spouštět úlohy sestavení.

Doporučení k návrhu

  • Pomocí CI můžete automatizovat sestavení a testování kódu pokaždé, když člen týmu potvrdí změny ve správě verzí.

  • Jako součást procesu sestavení zahrňte testy jednotek pro IaC a kód aplikace.

  • Pokud je to možné, použijte fond hostovaný Microsoftem místo fondů hostovaných v místním prostředí, protože nabízejí izolaci a čistý virtuální počítač pro každé spuštění kanálu.

  • Když připojíte Azure DevOps nebo GitHub k Azure prostřednictvím připojení služeb nebo tajných kódů GitHubu, ujistěte se, že vždy definujete rozsah, aby měli přístup jenom k požadovaným prostředkům.

  • Tajné kódy služby Key Vault použijte, abyste se vyhnuli pevnému kódování citlivých informací, jako jsou přihlašovací údaje (hesla uživatelů virtuálního počítače), certifikáty nebo klíče. Pak v úlohách sestavení a vydávání používejte tajné kódy jako proměnné.

Strategie nasazení

Aspekty návrhu

Doporučení k návrhu

  • Pomocí cd zajistíte, aby byl kód vždy připravený k nasazení, a to automatickým sestavováním, testováním a nasazováním kódu do produkčních prostředí. Přidejte průběžné doručování, abyste vytvořili úplnou integraci CI/CD, která vám pomůže co nejdříve rozpoznat chyby kódu a zajistit, abyste mohli rychle vydávat správně otestované aktualizace.

  • Používejte prostředí jako součást strategie nasazení. Prostředí poskytují výhody, jako jsou:

    • Historie nasazení
    • Sledovatelnost potvrzení a pracovních položek
    • Stav diagnostických prostředků
    • Zabezpečení

  • Zahrňte kontroly předběžného nasazení IaC, abyste mohli zobrazit náhled změn a zobrazit podrobnosti o tom, jestli se prostředek vytvoří, upraví nebo odstraní.

Strategie vrácení zpět

Aspekty návrhu

  • Zvažte vytvoření plánu vrácení zpět. Vrácení nasazení zpět zahrnuje vrácení nasazení do známého dobrého stavu a poskytuje zásadní schopnost zotavení z neúspěšného nasazení.

  • Pokud potřebujete vrátit změny v potvrzení, zahodit změny nebo obnovit větev do předchozího stavu, zvažte použití změn zpět v Gitu.

Doporučení k návrhu

  • Pokud potřebujete vrátit změny potvrzených souborů zpět, zahodit nepotvrzené změny nebo obnovit větev do předchozího stavu, použijte v Gitu změny zpět.