A szervezeti struktúra megtervezése

  • Cikk

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

Az üzleti struktúrát útmutatóként használhatja az Azure DevOpsban létrehozott szervezetek, projektek és csapatok számára. Ez a cikk segítséget nyújt az Azure DevOps különböző struktúráinak és forgatókönyveinek megtervezésében.

Vegye figyelembe az alábbi struktúrákat az Azure DevOpsban végzett üzleti és együttműködési munkához:

Érdemes lehet a következő forgatókönyveket is megtervezni:

Legalább egy olyan szervezettel rendelkezik, amely a vállalatot, a kódprojektek nagyobb gyűjteményét vagy akár több kapcsolódó üzleti egységet is képviselhet.

Mi az a szervezet?

Az Azure DevOpsban egy szervezet a kapcsolódó projektek csoportjainak rendszerezésére és összekapcsolására szolgáló mechanizmus. Ilyenek például az üzleti részlegek, a regionális részlegek vagy más vállalati struktúrák. Választhat egy szervezetet a teljes vállalathoz, egy szervezetet saját magának, vagy külön szervezetet adott üzleti egységekhez.

Minden szervezet saját ingyenes szolgáltatási szintet kap (minden szolgáltatástípushoz legfeljebb öt felhasználót) az alábbiak szerint. Használhatja az összes szolgáltatást, vagy kiválaszthatja, hogy mit kell kiegészítenie a meglévő munkafolyamatokkal.

  • Azure Pipelines: Egy üzemeltetett feladat, havonta 1800 perc ci/CD és egy saját üzemeltetésű feladat
  • Azure Boards: Munkaelem-követés és kanbantáblák
  • Azure Repos: Korlátlan számú Git-adattár
  • Azure Artifacts: Csomagkezelés
  • Korlátlan érdekelt felek
    • Első öt felhasználó ingyenes (alapszintű licenc)
    • Azure Pipelines
    • Azure Boards: Munkaelem-követés és kanbantáblák
    • Azure Repos: Korlátlan számú Git-adattár
    • Azure Artifacts: Szervezetenként két ingyenes GiB

Feljegyzés

Az Azure DevOps felhőalapú terheléstesztelési szolgáltatás elavult, de az Azure Load Testing továbbra is elérhető marad. Ez a teljes körűen felügyelt terheléstesztelési szolgáltatás lehetővé teszi, hogy nagy léptékű terhelést hozzon létre a meglévő Apache JMeter-szkriptek használatával. További információ: Mi az Az Azure Load Testing? és a Visual Studio terheléstesztelési funkcióinak változásai, valamint az Azure DevOps felhőbetöltési tesztelése.

Hány szervezetre van szüksége?

Kezdje egy szervezettel az Azure DevOpsban. Ezt követően később további szervezeteket is hozzáadhat – amelyekhez eltérő biztonsági modellekre lehet szükség. Egyetlen kódtárnak vagy projektnek csak egy szervezetre van szüksége. Ha különálló csapatokkal rendelkezik, amelyeknek külön-külön kell dolgozniuk a kódon vagy más projekteken, érdemes lehet külön szervezeteket létrehozni ezekhez a csapatokhoz. Különböző URL-címekkel fognak rendelkezni. Szükség szerint vegyen fel projekteket, csapatokat és adattárat, mielőtt egy másik szervezetet ad hozzá.

Szánjon egy kis időt, hogy áttekintse a munkastruktúrát, valamint a kezelendő különböző üzleti csoportokat és résztvevőket. További információ: Projektek leképezése üzleti egységekre és struktúra-szempontokra.

Tipp.

A vállalat tulajdonában lévő Microsoft Entra-szervezetek esetében érdemes korlátozni a felhasználókat abban, hogy új szervezeteket hozzanak létre az IP-cím védelme érdekében. További információ: Szervezetlétrehozás korlátozása a Microsoft Entra bérlői szabályzatán keresztül. A felhasználók korlátozás nélkül hozhatnak létre szervezeteket MSA- vagy GitHub-fiókjukkal.

Mi az a csapat?

A csapat egy olyan egység, amely számos , csapat által konfigurálható eszközt támogat. Ezekkel az eszközökkel megtervezheti és kezelheti a munkát, és egyszerűbbé teheti az együttműködést.

Csapat létrehozása minden egyes különálló termékhez vagy szolgáltatáscsoporthoz

Minden csapatnak saját hátraléka van. Új teendőlista létrehozásához hozzon létre egy új csapatot. Konfigurálja a csapatokat és a hátralékokat hierarchikus struktúrába, így a programtulajdonosok könnyebben nyomon követhetik a csapatok előrehaladását, kezelhetik a portfóliókat, és összegző adatokat hozhatnak létre. A csoport létrehozásakor létrejön egy csoportcsoport. Ezt a csoportot lekérdezésekben vagy a csapat engedélyeinek beállításához használhatja.

Mi az a projekt?

Az Azure DevOps-projektek a következő funkciókat tartalmazzák:

  • Táblák és hátralékok az agilis tervezéshez
  • Folyamatok a folyamatos integrációhoz és üzembe helyezéshez
  • Adattárak a forráskód és összetevők verziókövetéséhez és kezeléséhez
  • Folyamatos tesztelési integráció a projekt teljes életciklusa során Minden szervezet egy vagy több projektet tartalmaz

Az alábbi képen a fiktív Contoso vállalat négy projekttel rendelkezik a Contoso-Manufacturing vállalaton belül.

Négy projekttel rendelkező szervezet képe

Hány projektre van szüksége?

Legalább egy projektje van az Azure DevOps szolgáltatás ( például Az Azure Boards, az Azure Repos vagy az Azure Pipelines) használatának megkezdéséhez. A szervezet létrehozásakor a rendszer létrehoz egy alapértelmezett projektet. Az alapértelmezett projektben van egy kódtár, amelyben megkezdheti a munkát, hátralékot a munka nyomon követéséhez, és legalább egy folyamatot a build és a kiadás automatizálásának megkezdéséhez.

A szervezeten belül az alábbi módszerek egyikét használhatja:

  • Egyetlen projekt létrehozása, amely számos adattárat és csapatot tartalmaz
  • Hozzon létre számos projektet, amelyek mindegyike saját csapatokkal, adattárakkal, buildekkel, munkaelemekkel és egyéb elemekkel rendelkezik

Még ha sok csapat is több száz különböző alkalmazáson és szoftverprojekten dolgozik, egyetlen projekten belül kezelheti őket az Azure DevOpsban. Ha azonban részletesebb biztonságot szeretne kezelni a szoftverprojektek és a csapataik között, fontolja meg számos projekt használatát. A legmagasabb szintű elkülönítés egy olyan szervezet, amelyben minden szervezet egyetlen Microsoft Entra-bérlőhöz csatlakozik. Egyetlen Microsoft Entra-bérlő azonban számos Azure DevOps-szervezethez csatlakoztatható.

Feljegyzés

Ha a felhasználó láthatóságának és együttműködésének korlátozása adott projektekhez – előzetes verziójú funkció engedélyezve van a szervezet számára, a Projekt hatókörű felhasználók csoporthoz felvett felhasználók nem férhetnek hozzá azokhoz a projektekhez, amelyekhez nem lettek hozzáadva. További információ és fontos, biztonsággal kapcsolatos kihívások : A szervezet kezelése, A projektek felhasználói láthatóságának korlátozása stb.

Önálló projekt

Egyetlen projekt az összes munkát a teljes szervezet "portfólió" szintjén helyezi el. A munkája ugyanazokat az adattárakat és iterációs útvonalakat tartalmazza. Egyetlen projekttel a csapatok megosztják a forrásadattárakat, a builddefiníciókat, a kiadási definíciókat, a jelentéseket és a csomagcsatornákat. Előfordulhat, hogy nagy méretű terméke vagy szolgáltatása van, amelyet sok csapat felügyel. Ezek a csapatok szoros függőségekkel rendelkeznek a termék életciklusa során. Létrehozhat egy projektet, és csapatokkal és területútvonalak használatával oszthatja el a munkát. Ezzel a beállítással a csapatok betekintést kapnak egymás munkájába, így a szervezet továbbra is igazodik egymáshoz. A csapatok ugyanazt az osztályozást használják a munkaelemek nyomon követéséhez, így könnyebben kommunikálhatnak és konzisztensek maradhatnak.

Tipp.

Ha több csapat dolgozik ugyanazon a terméken, ha az összes csapat ugyanabban az iterációs ütemezésben van, akkor a csapatok igazodnak egymáshoz, és azonos ütemben adják meg az értéket. Az Azure DevOpsban működő szervezetünk például több mint 40 funkciócsoporttal és 500 felhasználóval rendelkezik egyetlen projekten belül – ez jól működik, mert mindannyian közös célokkal és közös kiadási ütemezéssel rendelkező, közös termékkészleten dolgozunk.

A nagy mennyiségű lekérdezés és tábla megnehezítheti a keresett adatok megtalálását. A termék architektúrájától függően ez a nehézség más területekre is kihathat, például buildekre, kiadásokra és adattárakra. Ügyeljen arra, hogy jó elnevezési konvenciókat és egyszerű mappastruktúrát használjon. Amikor hozzáad egy adattárat a projekthez, vegye figyelembe a stratégiáját, és állapítsa meg, hogy az adattár a saját projektjébe helyezhető-e el.

Sok projekt

A legjobban a termék szállításával határozhatja meg a projekt struktúráját. Ha több projekt is van, az átterheli az adminisztrációs terhet, és nagyobb önállóságot biztosít a csapatoknak a projekt irányításához a csapat döntése szerint. Emellett nagyobb ellenőrzést biztosít a biztonság és az eszközökhöz való hozzáférés felett a különböző projektekben. A csapat függetlensége sok projekttel azonban némi igazítási kihívást jelent. Ha minden projekt más folyamatot vagy iterációs ütemezést használ, az megnehezítheti a kommunikációt és az együttműködést, ha az osztályozások nem azonosak.

Tipp.

Ha ugyanazt a folyamatot és iterációs ütemezést használja az összes projektben, javul az adatok és a jelentések csapatok közötti összesítésének lehetősége.

Az Azure DevOps projektközi élményt nyújt a munka kezeléséhez.

A következő forgatókönyvek miatt érdemes lehet egy másik projektet hozzáadni:

  • A projekten belüli információkhoz való hozzáférés tiltása vagy kezelése
  • Egyéni munkakövetési folyamatok támogatása a szervezet adott üzleti egységeihez
  • A saját felügyeleti szabályzatokkal és rendszergazdákkal rendelkező, teljesen különálló üzleti egységek támogatása
  • A testreszabási tevékenységek tesztelésének támogatása vagy bővítmények hozzáadása a munkaprojekt módosításainak bevezetése előtt

Ha sok projektet fontolgat, vegye figyelembe, hogy a Git-adattár hordozhatósága megkönnyíti az adattárak (beleértve a teljes előzményeket) projektek közötti migrálását. Más előzmények nem migrálhatók a projektek között. Ilyenek például a leküldéses és lekéréses kérelmek előzményei.

Amikor a projekteket üzleti egységekhez rendeli, a vállalat egyetlen szervezetet kap, és számos projektet beállít egy vagy több, egy üzleti egységet képviselő projekttel. A vállalat összes Azure DevOps-eszköze ebben a szervezetben található, és egy adott régióban (például Nyugat-Európában) található. Tekintse meg az alábbi útmutatót a projektek üzleti egységekhez való leképezéséhez:

Egy projekt, sok csapat Egy szervezet, számos projekt és csapat Számos szervezet
Általános útmutató A legjobb a kisebb vagy nagyobb, nagy mértékben összehangolt csapatokkal rendelkező szervezetek számára. Jó, ha a különböző erőfeszítések különböző folyamatokat igényelnek. A TFS örökölt migrálásainak részeként és a szervezetek közötti szigorú biztonsági határok esetében hasznos. Több projekttel és csapattal használható az egyes szervezeteken belül.
Hangsor Több tízezer felhasználót és több száz csapatot támogat, de ebben a méretben a legjobb, ha minden csapat a kapcsolódó erőfeszítéseken dolgozik. Ugyanaz, mint egy projekt esetében, de sok projekt egyszerűbb lehet.
Folyamat Összehangolt folyamatok a csapatok között; a csapat rugalmassága a táblák, irányítópultok stb. testreszabásához. Független folyamatok minden projekthez. Például különböző munkaelem-típusok, egyéni mezők stb. Ugyanaz, mint sok projekt.
Együttműködés A legmagasabb alapértelmezett láthatóság és újrahasználat a különböző csapatok munka- és eszközegységei között. A jó láthatóság és az újrafelhasználás lehetséges, de egyszerűbb elrejteni az eszközöket a projektek között, akár szándékosak. A szervezetek rossz láthatósága, együttműködése és újrafelhasználása.
Összesítő jelentéskészítés és portfóliókezelés A legjobb lehetőség a csapatok közötti összesítésre és a csapatok közötti koordinációra. Jó jelentéskészítés lehetséges a projektek között. A projektközi összesítés és a csapatkoordináció nehezebb. Nincs összesítés vagy koordináció a szervezetek között.
Biztonság/elkülönítés Csoportszinten zárolhatja az objektumokat, de az alapértelmezett a nyílt láthatóság és az együttműködés. Jobb lehetőség a projektek közötti zárolásra. Alapértelmezés szerint jó láthatóságot biztosít a projekteken belül, és jó elkülönítést biztosít a projektek között. Szigorú határok a szervezetek között; kiváló elkülönítés és minimális megosztási képesség a szervezetek között.
Környezetváltás A legegyszerűbb, ha a csapatok együttműködnek, és a felhasználók váltanak az erőfeszítések között. A felhasználók viszonylag könnyen dolgozhatnak együtt, és környezeteket váltanak az erőfeszítések között. Nehezebb, ha a felhasználóknak különböző szervezeteken kell dolgozniuk.
Információ túlterhelése Alapértelmezés szerint minden eszköz látható azoknak a felhasználóknak, akik "kedvenceket" és hasonló mechanizmusokat használnak az "információ túlterhelésének" elkerülése érdekében. Csökkent az információ túlterhelésének kockázata; a legtöbb projektegység el van rejtve a projekthatárok között. A szervezetek eszközei elkülönítve vannak, így csökkentve az információk túlterhelésének kockázatát.
Rendszergazda terhelő többletterhelés Sok adminisztrációt delegálnak az egyes csapatoknak. A legegyszerűbb a felhasználói licenceléshez és a szervezeti szintű felügyelethez. További munkára lehet szükség, ha az erőfeszítések között igazításra van szükség. További adminisztráció a projekt szintjén. Nagyobb többletterhelés, de hasznos lehet, ha a projekteknek különböző adminisztratív igényei vannak. A több projekthez hasonlóan nagyobb adminisztrációs többletterhelés is jár, ami nagyobb rugalmasságot tesz lehetővé a cégek között.

Struktúraadattárak és verziókövetés egy projekten belül

Vegye figyelembe a korábban létrehozott és hozzáférésre szoruló szervezetek egyikére vonatkozó konkrét stratégiai munkát. Ezen információk segítségével nevezhet el és hozhat létre egy projektet. A projekt url-címe a szervezet alatt van meghatározva, amelyben létrehozta, és a következő címen érhető el: https://dev.azure.com/{organization-name}/{project-name}.

Konfigurálja a projektet a Project beállításai között.

Képernyőkép a Projekt beállításai gombról.

A projektek kezelésével kapcsolatos további információkért lásd : Projektek kezelése az Azure DevOpsban. Egy projektet áthelyezhet egy másik szervezetbe az adatok migrálásával. A projekt migrálásával kapcsolatos további információkért lásd a Migrálási lehetőségek című témakört.

Verziókövetés kezelése

Azokban a projektekben, ahol az Azure Repos szolgáltatás engedélyezve van, a verziókövetési adattárak tárolhatják és módosíthatják a kódot. Az adattárak konfigurálásakor vegye figyelembe az alábbi beállításokat.

Git és Team Foundation verziókövetés (TFVC)

Az Azure Repos a következő verziókövetési rendszereket kínálja a csapatok számára, hogy a következők közül választhatnak:

  • Git és TFVC. A projektek minden típusú adattárral rendelkezhetnek. Alapértelmezés szerint az új projektek üres Git-adattárral rendelkeznek. A Git nagy rugalmasságot biztosít a fejlesztői munkafolyamatokban, és szinte minden releváns eszközzel integrálható a fejlesztői ökoszisztémában. Bármely projekt használhatja a Git-adattárat. A projekthez hozzáadható Git-adattárak mennyisége nincs korlátozva.

A TFVC egy központi verziókövetési rendszer, amely szintén elérhető. A Gittel ellentétben egy projekthez csak egy TFVC-adattár engedélyezett. Az adattáron belül azonban mappák és ágak segítségével rendszerezheti a kódokat több termékhez és szolgáltatáshoz, ha szükséges. A projektek szükség esetén használhatják a TFVC-t és a Gitet is.

Egy és több adattár

Több adattárat kell beállítania egy projekten belül, vagy projektenként kell beállítania egy adattárat? Az alábbi útmutató az adattárak tervezési és adminisztrációs funkcióihoz kapcsolódik.

Egy több adattárat tartalmazó projekt akkor működik jól, ha a termékek/szolgáltatások összehangolt kiadási ütemterven dolgoznak. Ha a fejlesztők gyakran dolgoznak több adattárral, tartsa őket egyetlen projektben, hogy a folyamatok továbbra is megosztottak és konzisztensek maradjanak. Egyszerűbb az adattár-hozzáférés kezelése egyetlen projekten belül, mivel a hozzáférés-vezérlés és az olyan beállítások, mint az esetkényszerítés és a maximális fájlméret a projekt szintjén vannak beállítva. A hozzáférési vezérlőket és beállításokat külön is kezelheti, még akkor is, ha az adattárak egyetlen projektben találhatók.

Ha a több adattárban tárolt termékek független ütemezéseken vagy folyamatokon dolgoznak, több projektre oszthatja őket. A Git-adattár hordozhatósága megkönnyíti az adattár projektek közötti áthelyezését, és továbbra is megőrzi a teljes körű véglegesítési előzményeket. A többi előzmény, például a lekéréses kérelmek vagy a buildelőzmények nem könnyen migrálhatók.

A következő tényezőkre és tippekre alapozhatja a döntést egy vagy több adattár esetében:

  • kódfüggőségek és architektúra
  • minden önállóan üzembe helyezhető terméket vagy szolgáltatást saját adattárába helyezhet
  • ne különítse el a kódbázist több adattárra, ha összehangolt kódmódosításokat szeretne végrehajtani ezeken az adattárakon, mivel nincsenek olyan eszközök, amelyek segítenek összehangolni ezeket a módosításokat
  • ha a kódbázis már monolitikus, tartsa meg egy adattárban. További információ a monolitikus adattárakról: Hogyan fejleszt a Microsoft modern szoftvereket DevOps-cikkekkel
  • ha sok leválasztott szolgáltatással rendelkezik, szolgáltatásonként egy adattár jó stratégia

Tipp.

Fontolja meg az engedélyek kezelését, hogy a szervezeten belül ne mindenki hozzon létre adattárat. Ha túl sok adattárral rendelkezik, nehéz nyomon követni, hogy ki rendelkezik az adattárakban tárolt kóddal vagy más tartalommal.

Megosztott adattár és elágazott adattárak

Javasoljuk, hogy egy megbízható szervezeten belül használjon megosztott adattárat. A fejlesztők ágakat használnak a módosítások egymástól való elkülönítésének fenntartásához. Jó elágaztatási és kiadási stratégiával egyetlen adattár skálázható, így több mint ezer fejlesztő egyidejű fejlesztését támogathatja. További információ az elágaztatási és kiadási stratégiáról: Git-elágaztatási stratégia és kiadási folyamat: Elágaztatási stratégia.

Az elágazások akkor lehetnek hasznosak, ha olyan szállítói csapatokkal dolgozik, amelyeknek nem kellene közvetlen hozzáféréssel rendelkezniük a fő adattár frissítéséhez. Az elágazások olyan helyzetekben is hasznosak lehetnek, amikor sok fejlesztő ritkábban járul hozzá, például egy nyílt forráskódú projekthez. Ha elágazásokkal dolgozik, érdemes lehet külön projektet fenntartania, hogy elkülönítse az elágazott adattárakat a fő adattártól. Előfordulhat, hogy további adminisztratív többletterhelések merülnek fel, de a fő projekt tisztább marad. További információt az Elágazások című cikkben talál.

Az alábbi képen egy minta látható, amely bemutatja, hogyan strukturálhatja a "vállalata" a szervezeteit, projektjeit, munkaelemeit, csapatait és adattárait.

Egy vállalat szervezeti struktúráját bemutató ábra.

További információ a szervezeti struktúráról

A szervezeti rendszergazdai fiók típusának kiválasztása

Szervezet létrehozásakor a bejelentkezéshez használt hitelesítő adatok határozzák meg, hogy a szervezet melyik identitásszolgáltatót használja. A szervezet létrehozása Microsoft-fiókkal vagy Microsoft Entra-példánnyal. Ezekkel a hitelesítő adatokkal jelentkezzen be rendszergazdaként az új szervezetbe a következő helyen https://dev.azure.com/{YourOrganization}: .

A Microsoft-fiók használata

Használja a Microsoft-fiókját, ha nem kell microsoft entra-azonosítóval hitelesítenie egy szervezet felhasználóit. Minden felhasználónak Microsoft-fiókkal kell bejelentkeznie a szervezetbe. Ha nem rendelkezik ilyen fiókkal, hozzon létre egy Microsoft-fiókot.

Adja meg a jelszavát, és jelentkezzen be

Ha nincs Microsoft Entra-példánya, hozzon létre egyet ingyenesen az Azure Portalról , vagy a Microsoft-fiókjával hozzon létre egy szervezetet. Ezután csatlakoztathatja a szervezetet a Microsoft Entra-azonosítóhoz.

A Microsoft Entra-fiók használata

Előfordulhat, hogy már rendelkezik Microsoft Entra-fiókkal, ha az Azure-t vagy a Microsoft 365-öt használja. Ha olyan vállalatnál dolgozik, amely a Microsoft Entra-azonosítót használja a felhasználói engedélyek kezeléséhez, valószínűleg Microsoft Entra-fiókkal rendelkezik.

Ha nem rendelkezik Microsoft Entra-fiókkal, regisztráljon a Microsoft Entra-azonosítóra, hogy automatikusan összekapcsolja a szervezetet a Microsoft Entra-azonosítójával. A szervezet eléréséhez minden felhasználónak tagja kell lennie a címtárban. Más szervezetek felhasználóinak hozzáadásához használja a Microsoft Entra B2B együttműködést.

Az Azure DevOps a Microsoft Entra-azonosítóján keresztül hitelesíti a felhasználókat, így csak a címtárban tag felhasználók férhetnek hozzá a szervezethez. Amikor eltávolítja a felhasználókat a címtárból, azok már nem férhetnek hozzá a szervezethez. Csak bizonyos Microsoft Entra-rendszergazdák kezelik a címtárban lévő felhasználókat, így a rendszergazdák szabályozhatják, hogy ki fér hozzá a szervezethez.

További információ a felhasználók kezeléséről: Felhasználók kezelése.

Szervezetek hozzárendelése üzleti egységekhez

A vállalat minden egyes üzleti egysége saját szervezetet kap az Azure DevOpsban, valamint saját Microsoft Entra-bérlőt. Az egyes szervezeteken belül igény szerint állíthat be projekteket csapatok vagy folyamatban lévő munka alapján.

Nagyobb vállalatok esetén több szervezetet is létrehozhat különböző felhasználói fiókok (valószínűleg Microsoft Entra-fiókok) használatával. Fontolja meg, hogy mely csoportok és felhasználók osztják meg a stratégiákat és a munkát, és csoportosítsák őket adott szervezetekbe.

A fiktív Fabrikam vállalat például a következő három szervezetet hozta létre:

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

Minden szervezetnek külön URL-címe van, például:

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

A szervezetek ugyanahhoz a vállalathoz tartoznak, de többnyire el vannak különítve egymástól. Így nem kell különválasztania semmit. Csak akkor hozzon létre határokat, ha van értelme a vállalkozásnak.

Tipp.

A meglévő szervezeteket egyszerűbben particionálhatja projektekkel, mint a különböző szervezetek kombinálásával.