Plánování organizační struktury

  • Článek

Azure DevOps Services | Azure DevOps Server 2022 – Azure DevOps Server 2019

Obchodní strukturu použijte jako vodítko pro počet organizací, projektů a týmů, které vytvoříte v Azure DevOps. Tento článek vám pomůže naplánovat různé struktury a scénáře pro Azure DevOps.

Zvažte následující struktury pro vaši firmu a spolupráci v Azure DevOps:

Můžete také chtít naplánovat následující scénáře:

Mít alespoň jednu organizaci, která může představovat vaši společnost, větší kolekci projektů kódu nebo dokonce více souvisejících organizačních jednotek.

Co je organizace?

Organizace v Azure DevOps je mechanismus pro uspořádání a propojení skupin souvisejících projektů. Mezi příklady patří obchodní divize, regionální divize nebo jiné podnikové struktury. Můžete zvolit jednu organizaci pro celou společnost, jednu pro sebe nebo samostatnou organizaci pro konkrétní organizační jednotky.

Každá organizace získá vlastní bezplatnou úroveň služeb (až pět uživatelů pro každý typ služby) následujícím způsobem. Můžete použít všechny služby nebo zvolit jenom to, co potřebujete k doplnění stávajících pracovních postupů.

  • Azure Pipelines: Jedna hostovaná úloha s 1 800 minutami za měsíc pro CI/CD a jednu úlohu v místním prostředí
  • Azure Boards: sledování pracovních položek a karty Kanban
  • Azure Repos: neomezená privátní úložiště Git
  • Azure Artifacts: správa balíčků
  • Neomezený počet zúčastněných stran
    • Prvních pět uživatelů zdarma (licence Basic)
    • Azure Pipelines
      • Jedna CI/CD hostovaná Microsoftem (jedna souběžná úloha, až 30 hodin za měsíc)
      • Jedna souběžná úloha CI/CD v místním prostředí
    • Azure Boards: sledování pracovních položek a karty Kanban
    • Azure Repos: neomezená privátní úložiště Git
    • Azure Artifacts: Dva GiB zdarma na organizaci

Poznámka:

Cloudová služba zátěžového testování Azure DevOps je zastaralá, ale zátěžové testování Azure zůstává dostupné. Tato plně spravovaná služba zátěžového testování umožňuje generovat zatížení ve velkém měřítku pomocí existujících skriptů Apache JMeter. Další informace najdete v tématu Co je zátěžové testování Azure? a změny funkcí zátěžového testu v sadě Visual Studio a cloudovém zátěžového testování v Azure DevOps.

Kolik organizací potřebujete?

Začněte s jednou organizací v Azure DevOps. Pak můžete později přidat další organizace, které můžou vyžadovat různé modely zabezpečení. Jedno úložiště kódu nebo projekt potřebuje jenom jednu organizaci. Pokud máte samostatné týmy, které potřebují pracovat na kódu nebo jiných projektech izolovaně, zvažte vytvoření samostatných organizací pro tyto týmy. Budou mít různé adresy URL. Před přidáním jiné organizace přidejte projekty, týmy a úložiště podle potřeby.

Zkontrolujte svoji pracovní strukturu a různé obchodní skupiny a účastníky, které se mají spravovat. Další informace najdete v tématu Mapování projektů na obchodní jednotky a aspekty struktury.

Tip

U organizací Microsoft Entra vlastněných společností zvažte omezení uživatelů v vytváření nových organizací jako způsob, jak chránit vaši IP adresu. Další informace najdete v tématu Omezení vytváření organizace prostřednictvím zásad tenanta Microsoft Entra. Uživatelé můžou vytvářet organizace pomocí svých účtů MSA nebo GitHub bez omezení.

Co je tým?

Tým je jednotka, která podporuje mnoho nástrojů konfigurovatelných týmem. Tyto nástroje vám pomůžou plánovat a spravovat práci a usnadňují spolupráci.

Vytvoření týmu pro každý samostatný produkt nebo tým funkcí

Každý tým vlastní vlastní backlog. Pokud chcete vytvořit nový backlog, vytvořte nový tým. Nakonfigurujte týmy a backlogy do hierarchické struktury, aby vlastníci programů mohli snadněji sledovat průběh napříč týmy, spravovat portfolia a generovat souhrnná data. Týmová skupina se vytvoří při vytváření týmu. Tuto skupinu můžete použít v dotazech nebo nastavit oprávnění pro váš tým.

Co je projekt?

Projekt v Azure DevOps obsahuje následující sadu funkcí:

  • Panely a backlogy pro agilní plánování
  • Kanály pro kontinuální integraci a nasazování
  • Úložiště pro správu verzí a správu zdrojového kódu a artefaktů
  • Kontinuální integrace testů v průběhu životního cyklu projektu Každá organizace obsahuje jeden nebo více projektů.

Na následujícím obrázku má fiktivní společnost Contoso čtyři projekty ve své organizaci Contoso-Manufacturing.

Obrázek organizace se čtyřmi projekty

Kolik projektů potřebujete?

Pokud chcete začít používat službu Azure DevOps, například Azure Boards, Azure Repos nebo Azure Pipelines, požádejte alespoň jeden projekt. Když vytvoříte organizaci, vytvoří se vám výchozí projekt. Ve výchozím projektu je úložiště kódu, ve kterém můžete začít pracovat, backlog sledovat práci a aspoň jeden kanál, který začne automatizovat sestavování a vydávání.

V rámci organizace můžete provést některý z následujících přístupů:

  • Vytvoření jednoho projektu, který obsahuje mnoho úložišť a týmů
  • Vytváření mnoha projektů s vlastní sadou týmů, úložišť, sestavení, pracovních položek a dalších prvků

I když máte mnoho týmů pracujících na stovkách různých aplikací a softwarových projektů, můžete je spravovat v rámci jednoho projektu v Azure DevOps. Pokud ale chcete spravovat podrobnější zabezpečení mezi softwarovými projekty a jejich týmy, zvažte použití mnoha projektů. Na nejvyšší úrovni izolace je organizace, ve které je každá organizace připojená k jednomu tenantovi Microsoft Entra. Jeden tenant Microsoft Entra ale může být připojený k mnoha organizacím Azure DevOps.

Poznámka:

Pokud je pro organizaci povolená funkce Omezit viditelnost uživatelů a spolupráci na konkrétní projekty ve verzi Preview, uživatelé přidaní do skupiny Uživatelé s vymezeným projektem nebudou mít přístup k projektům, ke kterým nebyli přidáni. Další informace a důležité popisky související se zabezpečením najdete v tématu Správa organizace, omezení viditelnosti uživatelů pro projekty a další.

Jeden projekt

Jeden projekt umístí veškerou práci na stejné úrovni "portfolia" pro celou organizaci. Vaše práce má stejnou sadu úložišť a iteračních cest. S jedním projektem týmy sdílejí zdrojová úložiště, definice sestavení, definice verzí, sestavy a informační kanály balíčků. Možná máte velký produkt nebo službu, kterou spravuje mnoho týmů. Tyto týmy mají úzké vzájemné závislosti v životním cyklu produktu. Vytvoříte projekt a rozdělíte práci pomocí týmů a cest oblastí. Toto nastavení dává týmům přehled o práci ostatních, takže organizace zůstane v souladu. Vaše týmy používají stejnou taxonomii pro sledování pracovních položek, což usnadňuje komunikaci a udržování konzistentního fungování.

Tip

Pokud na stejném produktu pracuje více týmů, může mít všechny týmy ve stejném plánu iterace stejnou hodnotu a zajistit tak stejnou frekvenci. Naše organizace v Azure DevOps má například více než 40 týmů funkcí a 500 uživatelů v rámci jednoho projektu . To funguje dobře, protože pracujeme na společném produktu nastaveném se společnými cíli a společným plánem vydávání verzí.

Velký objem dotazů a panelů může ztěžovat nalezení toho, co hledáte. V závislosti na architektuře vašeho produktu může být tento problém přesahován do jiných oblastí, jako jsou buildy, vydané verze a úložiště. Ujistěte se, že používáte dobré zásady vytváření názvů a jednoduchou strukturu složek. Když do projektu přidáte úložiště, zvažte strategii a určete, jestli by se toto úložiště dalo umístit do vlastního projektu.

Mnoho projektů

Strukturu projektu můžete nejlépe určit tak, jak produkt odešlete. Několik projektů přesouvá administrativní zátěž a dává týmům větší autonomii při správě projektu, jak se tým rozhodne. Poskytuje také větší kontrolu nad zabezpečením a přístupem k prostředkům v různých projektech. Mít nezávislost týmu s mnoha projekty ale přináší určité problémy sladění. Pokud každý projekt používá jiný proces nebo plán iterace, může být komunikace a spolupráce obtížná, pokud taxonomie nejsou stejné.

Tip

Pokud používáte stejný proces a plány iterací ve všech svých projektech, zlepší se možnost zahrnout data a sestavy napříč týmy.

Azure DevOps poskytuje prostředí napříč projekty pro správu práce.

Kvůli následujícím scénářům můžete chtít přidat další projekt:

  • Zakázání nebo správa přístupu k informacím v projektu
  • Podpora vlastních procesů sledování práce pro konkrétní organizační jednotky ve vaší organizaci
  • Podpora zcela oddělených organizačních jednotek, které mají vlastní zásady správy a správce
  • Podpora testování aktivit přizpůsobení nebo přidání rozšíření před zavedením změn pracovního projektu

Při zvažování mnoha projektů mějte na paměti, že přenositelnost úložiště Git usnadňuje migraci úložišť (včetně úplné historie) mezi projekty. Mezi projekty nelze migrovat další historii. Příklady jsou historie nabízených změn a žádostí o přijetí změn.

Když mapujete projekty na organizační jednotky, vaše společnost získá jednu organizaci a nastaví mnoho projektů s jedním nebo více projekty představujícími obchodní jednotku. Všechny prostředky Azure DevOps společnosti jsou obsaženy v této organizaci a nacházejí se v dané oblasti (například v západní Evropě). Při mapování projektů na organizační jednotky zvažte následující doprovodné materiály:

Jeden projekt, mnoho týmů Jedna organizace, mnoho projektů a týmů Mnoho organizací
Obecné pokyny Nejvhodnější pro menší organizace nebo větší organizace s vysoce sladěnými týmy. Dobré, když různé snahy vyžadují různé procesy. Užitečné jako součást starších migrací TFS a pro pevné hranice zabezpečení mezi organizacemi. Používá se s více projekty a týmy v rámci každé organizace.
Měřítko Podporuje desítky tisíc uživatelů a stovek týmů, ale nejlépe v tomto měřítku, pokud všechny týmy pracují na souvisejícím úsilí. Stejné jako u jednoho projektu, ale mnoho projektů může být jednodušší.
Proces Sladěné procesy napříč týmy; Flexibilita týmu pro přizpůsobení panelů, řídicích panelů atd. Nezávislé procesy pro každý projekt. Například různé typy pracovních položek, vlastní pole atd. Stejné jako mnoho projektů.
Spolupráce Nejvyšší výchozí viditelnost a opakované použití mezi prací a prostředky různých týmů. Je možné získat dobrou viditelnost a opakované použití, ale je jednodušší skrýt prostředky mezi projekty, ať jsou úmyslné. Špatná viditelnost, spolupráce a opakované použití mezi organizacemi.
Zavedení vytváření sestav a správy portfolia Nejlepší schopnost shrnovat týmy a koordinovat mezi týmy. Dobré vytváření sestav napříč projekty. Obtížnější pro koordinaci mezi projekty a týmovou koordinaci. Mezi organizacemi není žádná spolupráce ani koordinace.
Zabezpečení/izolace Může uzamknout prostředky na úrovni týmu, ale ve výchozím nastavení je otevřená viditelnost a spolupráce. Lepší schopnost uzamknout mezi projekty. Ve výchozím nastavení poskytuje dobrou viditelnost v rámci projektů a dobrou izolaci napříč projekty. Pevné hranice napříč organizacemi; vynikající izolace a minimální schopnost sdílet mezi organizacemi.
Přepínání kontextu Nejjednodušší je, aby týmy spolupracovaly a aby uživatelé mohli přepínat mezi úsilím. Relativně snadné pro uživatele spolupracovat a přepínat kontexty mezi úsilím. Pro uživatele, kteří musí pracovat v různých organizacích, je obtížnější.
Přetížení informací Ve výchozím nastavení jsou všechny prostředky viditelné uživatelům, kteří používají "oblíbené" a podobné mechanismy, aby se zabránilo "přetížení informací". Snížené riziko přetížení informací; většina prostředků projektu skrytých přes hranice projektu. Prostředky napříč organizacemi jsou izolované a snižují riziko přetížení informací.
Správa istrativní režie Mnoho správy je delegováno na jednotlivé týmy. Nejjednodušší pro licencování uživatelů a správu na úrovni organizace. V případě potřeby sladění mezi úsilím může být potřeba více práce. Další správa na úrovni projektu. Větší režijní náklady, ale může být užitečné, když mají projekty různé potřeby správy. Stejně jako u více projektů existuje větší režijní náklady na správu, což umožňuje větší flexibilitu mezi organizací.

Strukturování úložišť a správy verzí v rámci projektu

Zvažte konkrétní strategickou práci vymezenou na jednu z organizací, které jste vytvořili dříve a kteří potřebují přístup. Tyto informace použijte k pojmenování a vytvoření projektu. Tento projekt má definovanou adresu URL v organizaci, ve které jste ho vytvořili, a můžete k němu získat přístup na adrese

Nakonfigurujte projekt v nastavení projectu.

Snímek obrazovky s tlačítkem Nastavení projektu

Další informace o správě projektů najdete v tématu Správa projektů v Azure DevOps. Projekt můžete přesunout do jiné organizace migrací dat. Další informace o migraci projektu najdete v tématu Možnosti migrace.

Správa správy verzí

V projektech, kde je povolená služba Azure Repos, můžou úložiště správy verzí ukládat a revidovat kód. Při konfiguraci úložišť zvažte následující možnosti.

Git vs. Správa verzí Team Foundation (TFVC)

Azure Repos nabízí pro týmy následující systémy správy verzí, ze kterých si můžou vybírat:

  • Git a TFVC Projekty můžou mít úložiště jednotlivých typů. Ve výchozím nastavení mají nové projekty prázdné úložiště Git. Git umožňuje velkou flexibilitu v pracovních postupech vývojářů a integruje se s téměř každým relevantním nástrojem v ekosystému vývojářů. Jakýkoli projekt může používat úložiště Git. Množství úložišť Git, která je možné přidat do projektu, není nijak omezena.

TFVC je centralizovaný systém správy verzí, který je k dispozici také. Na rozdíl od Gitu je pro projekt povolené jenom jedno úložiště TFVC. V rámci daného úložiště, složek a větví se ale v případě potřeby používají k uspořádání kódu pro více produktů a služeb. Projekty můžou v případě potřeby používat TFVC i Git.

Jeden vs. mnoho úložišť

Potřebujete nastavit více úložišť v rámci jednoho projektu nebo máte nastavené úložiště pro každý projekt? Následující pokyny se týkají funkcí plánování a správy napříč těmito úložištěmi.

Jeden projekt obsahující více úložišť funguje dobře, pokud produkty/služby pracují na koordinovaném plánu vydávání verzí. Pokud vývojáři často pracují s několika úložištěmi, udržujte je v jednom projektu, abyste zajistili, že procesy zůstanou sdílené a konzistentní. Správa přístupu k úložišti v rámci jednoho projektu je jednodušší, protože řízení přístupu a možnosti, jako je vynucení případu a maximální velikost souboru, se nastaví na úrovni projektu. Řízení přístupu a nastavení můžete spravovat jednotlivě, i když jsou vaše úložiště v jednom projektu.

Pokud produkty uložené v několika úložištích pracují na nezávislých plánech nebo procesech, můžete je rozdělit do více projektů. Přenositelnost úložiště Git usnadňuje přesun úložiště mezi projekty a zachování historie potvrzení v plné věrnosti. Jiné historie, jako jsou žádosti o přijetí změn nebo historie sestavení, se nemigrují snadno.

Založte své rozhodnutí pro jednu vs. řadu úložišť na následujících faktorech a tipech:

  • Závislosti kódu a architektura
  • umístit každý nezávisle nasazený produkt nebo službu do vlastního úložiště
  • neoddělujte základ kódu do mnoha úložišť, pokud očekáváte, že v těchto reposech provedete koordinované změny kódu, protože žádné nástroje nebudou moct tyto změny koordinovat.
  • pokud už je základ kódu monolitický, ponechte ho v jednom úložišti. Další informace o monolitických repozích najdete v článcích o vývoji moderního softwaru pomocí DevOps .
  • Pokud máte mnoho odpojených služeb, je vhodné pro každou službu jeden úložiště.

Tip

Zvažte správu oprávnění, takže úložiště můžou vytvářet všichni uživatelé ve vaší organizaci. Pokud máte příliš mnoho úložišť, je obtížné sledovat, kdo vlastní kód nebo jiný obsah uložený v těchto úložištích.

Sdílené úložiště vs. forkovaná úložiště

Doporučujeme použít sdílené úložiště v rámci důvěryhodné organizace. Vývojáři používají větve k zachování izolace svých změn mezi sebou. Díky dobré strategii větvení a vydávání verzí může jedno úložiště škálovat, aby podporovalo souběžný vývoj pro více než tisíc vývojářů. Další informace o strategii větvení a vydávání verzí najdete v tématu Přijetí strategie větvení Gitu a toku vydání: Naše strategie větvení.

Forky můžou být užitečné, když pracujete s týmy dodavatelů, které by neměly mít přímý přístup k aktualizaci hlavního úložiště. Forky můžou být užitečné i ve scénářích, kdy mnoho vývojářů přispívá zřídka, například v opensourcového projektu. Při práci s forky můžete chtít zachovat samostatný projekt, který izoluje rozvětvěná úložiště od hlavního úložiště. Může se přidat administrativní režie, ale udržuje hlavní projekt čistější. Další informace najdete v článku Forks.

Následující obrázek ukazuje, jak může vaše společnost strukturovat své organizace, projekty, pracovní položky, týmy a úložiště.

Diagram znázorňující organizační strukturu pro společnost

Další informace o organizační struktuře

Zvolte typ účtu správce vaší organizace.

Když vytvoříte organizaci, přihlašovací údaje, které se přihlásíte, definují, jakého zprostředkovatele identity vaše organizace používá. Vytvořte organizaci pomocí účtu Microsoft nebo instance Microsoft Entra. Pomocí těchto přihlašovacích údajů se přihlaste jako správce ve vaší nové organizaci na adrese https://dev.azure.com/{YourOrganization}.

Použití účtu Microsoft

Účet Microsoft použijte, pokud nepotřebujete ověřovat uživatele v organizaci pomocí ID Microsoft Entra. Všichni uživatelé se musí přihlásit k vaší organizaci pomocí účtu Microsoft. Pokud ho nemáte, vytvořte si účet Microsoft.

Zadejte heslo a přihlaste se.

Pokud nemáte instanci Microsoft Entra, vytvořte si ji zdarma na webu Azure Portal nebo použijte svůj účet Microsoft k vytvoření organizace. Pak můžete svou organizaci připojit k Microsoft Entra ID.

Použití účtu Microsoft Entra

Pokud používáte Azure nebo Microsoft 365, možná už máte účet Microsoft Entra. Pokud pracujete pro společnost, která ke správě uživatelských oprávnění používá Microsoft Entra ID, pravděpodobně máte účet Microsoft Entra.

Pokud nemáte účet Microsoft Entra, zaregistrujte si Microsoft Entra ID, aby se vaše organizace automaticky připojila k vašemu ID Microsoft Entra. Všichni uživatelé musí být členy v daném adresáři, aby měli přístup k vaší organizaci. Pokud chcete přidat uživatele z jiných organizací, použijte spolupráci Microsoft Entra B2B.

Azure DevOps ověřuje uživatele prostřednictvím vašeho ID Microsoft Entra, aby k vaší organizaci měli přístup jenom uživatelé, kteří jsou členy v daném adresáři. Když odeberete uživatele z daného adresáře, nebudou už mít přístup k vaší organizaci. Pouze konkrétní správci Microsoft Entra spravují uživatele ve vašem adresáři, takže správci řídí, kdo přistupuje k vaší organizaci.

Další informace o správě uživatelů najdete v tématu Správa uživatelů.

Mapování organizací na organizační jednotky

Každá obchodní jednotka ve vaší společnosti získá vlastní organizaci v Azure DevOps spolu s vlastním tenantem Microsoft Entra. Podle potřeby můžete nastavit projekty v rámci těchto jednotlivých organizací na základě týmů nebo probíhající práce.

U větší společnosti můžete vytvořit více organizací pomocí různých uživatelských účtů (s největší pravděpodobností účty Microsoft Entra). Zvažte, jaké skupiny a uživatelé sdílejí strategie a pracují, a seskupte je do konkrétních organizací.

Fiktivní společnost Fabrikam například vytvořila následující tři organizace:

  • Fabrikam-Marketing
  • Fabrikam -Engineering
  • Fabrikam-Sales

Každá organizace má samostatnou adresu URL, například:

  • https://dev.azure.com/Fabrikam-Marketing
  • https://dev.azure.com/Fabrikam-Engineering
  • https://dev.azure.com/Fabrikam-Sales

Organizace jsou určené pro stejnou společnost, ale většinou jsou navzájem izolované. Tímto způsobem nemusíte nic oddělit. Hranice můžete vytvářet jenom tehdy, když dává smysl pro vaši firmu.

Tip

Existující organizaci můžete snadněji rozdělit na projekty, než kombinovat různé organizace.