A szervezeti struktúra megtervezése

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022

Az üzleti struktúrát útmutatóként használhatja az Azure DevOpsban létrehozott szervezetek, projektek és csapatok számára. Ez az átfogó tervezési útmutató segít optimális szervezeti struktúrák kialakításában, amelyek a fejlesztési munkafolyamatokat az üzleti célkitűzésekhez igazítják.

Tipp.

A jelen cikk későbbi részében használhatja az AI-t, hogy segítsen ebben a feladatban, vagy olvassa el , hogyan engedélyezheti az AI-támogatást az Azure DevOps MCP Serverrel, és kezdje el.

Stratégiai tervezési keretrendszer

Az alábbi keretrendszer használatával minden szinten – szervezet, projekt, csapat és adattár – hozhat kulcsfontosságú döntéseket az Azure DevOps-struktúrával kapcsolatban.

Elsődleges struktúra-döntések

Az Azure DevOps-struktúra irányításához az alábbi alapvető kérdéseket kell megválaszolnia:

Szervezeti szint:

Hány szervezetre van szüksége? - Fontolja meg a biztonságot, a megfelelőséget és az üzleti egységek elkülönítését.
Szervezetek hozzárendelése üzleti egységekhez – Igazodás a vállalati struktúra és a szabályozási igényekhez.

Projektszint:

Hány projektre van szüksége? - Egyensúlyba hozhatja az együttműködést a biztonsággal és az önállósággal.
Projektleképezési stratégiák – Projektek csatlakoztatása üzleti funkciókhoz és csapatstruktúrákhoz.

Csapat- és adattárszint:

Csapatstruktúra kialakítása – Optimalizálja az agilis kézbesítést és a termék tulajdonjogát.
Adattár-szervezet – A fejlesztési és üzembehelyezési munkafolyamatok támogatása.

Támogatási szempontok

Hozzáférés-kezelés: Meghatározza, hogy kinek kell hozzáférnie ahhoz, hogy milyen információkhoz és erőforrásokhoz.
Jelentéskészítési követelmények: Csapatközi láthatóság és portfóliókezelés tervezése.
Folyamatszabványosítás: Konzisztens eljárások előmozdítása a csapat rugalmasságának biztosítása mellett.
Kulturális igazodás: Az agilis gondolkodásmód és az együttműködési kultúra előmozdítása.

Tipp.

Kezdje egyszerűbb struktúrákkal, és fejlődjön a szervezet növekedésével. Egyszerűbb felosztani egy nagy projektet, mint különálló szervezeteket egyesíteni.

Az Azure DevOps-szervezetek ismertetése

Az Azure DevOpsban egy szervezet szolgál a projektek legfelső szintű tárolójaként, amely számlázási, biztonsági és adminisztratív határokat biztosít. A szervezetek használatával a következő megoldásokat használhatja:

A számlázás és a licencelés központosítása a kapcsolódó projektek és csapatok között.
Hozzon létre biztonsági határokat különböző hozzáférés-vezérlésekkel és szabályzatokkal.
Adminisztratív elkülönítés biztosítása különböző üzleti egységekhez vagy megfelelőségi követelményekhez.
Csatlakozzon olyan identitásszolgáltatókhoz , mint a Microsoft Entra ID az egységes hitelesítéshez.

Szervezeti előnyök és ingyenes szint

Minden szervezet legfeljebb öt felhasználó számára tartalmaz ingyenes szintű szolgáltatásokat:

Service	Ingyenes szint előnyei
Azure Pipelines	Egy üzemeltetett feladat havonta 1800 perccel a CI/CD esetében, valamint egy saját üzemeltetésű feladat
Azure Boards	Munkaelemek nyomon követése és Kanban-táblák projektvezetéshez
Azure-tárházak	Korlátlan privát Git-adattárak a forráskezeléshez
Azure Artifacts	Csomagkezelés függőségekhez és buildösszetevőkhöz
Az érdekelt felek hozzáférése	Korlátlan érdekelt felek a megtekintéshez és az alapszintű projektben való részvételhez

Első öt felhasználó ingyenes (alapszintű licenc)
Azure Pipelines:
- Egy Microsoft által üzemeltetett CI/CD (egy egyidejű feladat, havonta legfeljebb 30 óra)
- Egy saját üzemeltetésű CI/CD egyidejű munka
Azure Boards: Munkaelemek nyomon követése és tá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.

Gyakori szervezeti minták:

Egyetlen szervezet: Egyetlen szervezet használata az egységes együttműködéshez.
Üzleti egységek szervezetei: Külön szervezeteket használjon a különböző megfelelőségi vagy biztonsági követelményekhez.
Földrajzi szervezetek: Használjon területi elkülönítést az adattároláshoz vagy a helyi irányításhoz.

Hány szervezetre van szüksége?

Kezdje egy szervezettel , és csak akkor bontsa ki a elemet, ha meghatározott üzleti követelményei vannak, amelyek elkülönítést igényelnek.

Több szervezet döntési feltételei

Szükség esetén hozzon létre további szervezeteket:

Biztonság és megfelelőség elkülönítése:

Különböző szabályozási követelmények, például SOX, HIPAA vagy PCI-DSS
Eltérő ügyféladat-elkülönítési követelmények
Külön auditnaplók és megfelelőségi jelentések

Az üzleti struktúra követelményei:

Független üzleti egységek külön informatikai irányítással
Különböző számlázási és költséghelyi követelmények
Különböző identitásszolgáltatói kapcsolatok, például különböző Microsoft Entra-bérlők

Adminisztratív határok:

Különböző rendszergazdai csoportok átfedés nélkül
Szervezeti szabályzatok és vezérlők elkülönítése
Független szolgáltatásiszint-szerződések

Értékelési keretrendszer

Tényező	Önálló szervezet	Több szervezet
Együttműködés	Maximális láthatóság és megosztás	Izolált, korlátozott szervezetközi megosztás
Adminisztráció	Központosított, egyszerűbb felügyelet	Elosztott, nagyobb adminisztrációs többletterhelés
Jelentéskészítés	Egyesített irányítópultok és elemzések	Külön jelentéskészítési rendszerek
Cost	Egyetlen számlázási entitás	Több számlázási entitás
Security	Közös határok, egységesített szabályzatok	Kemény határok, független szabályzatok

Fontos

A vállalat tulajdonában lévő Microsoft Entra-szervezetek esetében fontolja meg a szervezetlétrehozás korlátozását a szellemi tulajdon védelme és az irányítás fenntartása érdekében.

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. Csapat létrehozásakor egy csoportcsoportot is létre kell hoznia. Ezt a csoportot lekérdezésekben vagy a csapat engedélyeinek beállításához használhatja.

A projektek ismertetése

A projektek biztosítják a tárolót a fejlesztési munkához, amely az alábbi integrált szolgáltatásokat tartalmazza:

Azure Boards: Agilis tervezés hátralékokkal, sprintekkel és munkatételkövetéssel.
Azure Pipelines: Folyamatos integráció és üzembe helyezés automatizálása.
Azure-adattárak: Git- vagy TFVC-adattárak a forráskódkezeléshez.
Azure Test Plans: Manuális és automatizált tesztelési integráció.
Megosztott erőforrások: Wiki, irányítópultok és projektszintű beállítások.

Az alábbi példában a Contoso Manufacturing négy projektet használ a különböző terméksorok rendszerezéséhez:

Diagram egy négy projekttel rendelkező szervezetről.

A projekt előnyei és szempontjai

A projektek lehetővé teszik:

Megosztott iterációs ütemezések és osztályozás a csapatok között.
Konzisztens folyamatsablonok és munkaelem-típusok.
Integrált jelentéskészítés és portfóliókezelés.
Egyszerűsített felhasználói felügyelet és hozzáférés-vezérlés.

A projektek a következő határokat biztosítják:

Biztonsági és hozzáférési engedélyek.
Folyamat testreszabása és a munka nyomon követése.
Felügyeleti szabályzatok és irányítás.
Erőforrás-kiosztás és számlázás nyomon követése.

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 saját maga hoz létre egy alapértelmezett projektet. Az alapértelmezett projektben van egy kódtár, amelyben megkezdheti a munkát, egy 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:

Hozzon létre egyetlen projektet, 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, melyben 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 engedélyezi a felhasználók láthatóságának és együttműködésének korlátozása a szervezet adott projektjeinek előzetes verziójára vonatkozó funkcióját, a Project-Scoped Felhasználók csoporthoz hozzáadott felhasználók nem férhetnek hozzá azokhoz a projektekhez, amelyekhez nem lettek hozzáadva. További információért és fontos, biztonsággal kapcsolatos figyelmeztetésekért lásd: A szervezet kezelése, A projektek felhasználói láthatóságának korlátozása és más hasonló témák.

Projektdöntési keretrendszer

Válassza ki a megfelelő projektstruktúrát az együttműködési igények alapján:

Egyetlen projekt megközelítése:

A legjobb megoldás: Kisebb szervezetek vagy csapatok szoros együttműködéssel
Előnyök: Maximális láthatóság, megosztott erőforrások, egységes jelentéskészítés
Fontolja meg, hogy mikor: A Teams hasonló kiadási ciklusokkal rendelkező kapcsolódó termékeken dolgozik

Több projekt megközelítése:

Legjobban a következőhöz használható: Különálló követelményekkel rendelkező független csapatok
Előnyök: Jobb biztonsági határok, testreszabható folyamatok, csapat autonómia
Fontolja meg, hogy mikor: Különböző megfelelőségi igények vagy különálló üzleti egységek

Az Azure DevOps projektközi élményt nyújt a több projekten belüli munka kezeléséhez.

Fontolja meg több projekt lehetőségét:

Adott információkhoz való hozzáférés korlátozása vagy kezelése
Egyéni munkakövetési folyamatok támogatása különböző üzleti egységekhez
Különálló üzleti egységek támogatása független felügyeleti szabályzatokkal
Testreszabások vagy bővítmények tesztelése az éles bevezetés előtt

Fontos

A Git-adattár hordozhatósága megkönnyíti az adattárak projektek közötti migrálását (beleértve a teljes előzményt is). Más előzményeket, például leküldéses és lekéréses kérelmeket azonban nem migrálhat a projektek között.

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. Ez a szervezet a vállalat összes Azure DevOps-eszközét tartalmazza, és egy adott földrajzi helyen (például 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ás	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.	Az örökölt migrálások 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.
Skálázás	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ékosan is.	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.
Rendszergazdai 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

Gondolja át a korábban létrehozott szervezetek egyikével kapcsolatos konkrét stratégiai munkát, és azt, hogy kinek van szüksége hozzáférésre. Ezen információk segítségével nevezhet el és hozhat létre egy projektet. Ez a projekt egy URL-címet határoz meg a szervezet alatt, amelyben létrehozta, és a következő címen https://dev.azure.com/{organization-name}/{project-name}érheti el: .

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 tekintse meg a Migrálás áttekintését.

Adattárstratégia és verziókövetés

Konfigurálja az adattár stratégiáját a csoportméret, a termékarchitektúra és az üzembe helyezési követelmények alapján.

Verziókövetési rendszer kiválasztása

Válasszon a Git és a Team Foundation verziókövetés (TFVC) közül:

Git-adattárak:

Ajánlott megközelítés modern fejlesztési munkafolyamatokhoz
Projektenként korlátlan tárházak
Elosztott verziókövetés rugalmas elágazással
Integrálható a legtöbb fejlesztőeszközzel és CI/CD-rendszerrel

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

Központi verziókövetési rendszer
Projektenként egyetlen adattár mappaalapú szervezettel
Alkalmas a központosított munkafolyamatokat előnyben részesítő csapatok számára

Tipp.

A projektek git- és TFVC-adattárakat is használhatnak, ha a csapatok eltérő munkafolyamat-beállításokat használnak.

Adattár szervezeti mintái

Monorepo stratégia:

Legjobb megoldás: A kis csapatok lendületet építenek a kapcsolódó szolgáltatásokkal
Előnyök: Egyszerűsített megosztás és összehangolt módosítások
Kihívások: A tudás összetettsége a csapat növekedésével nő; nem szándékos szolgáltatáskapcsolódás; nehéz változáskövetés

Külön adattárak stratégiája:

A legjobb megoldás: Nagyobb csapatok független szolgáltatástelepítésekkel
Előnyök: Szolgáltatáshatárok törlése, egyszerűbb előkészítés, független kiadási ciklusok
Megfontolandó szempontok: Több kezdeti beállítást igényel, de hatékonyan skálázható a csapat növekedésével.

Tipp.

Kezdje monorepóval, ha kis csapatokkal dolgozik, majd a szervezet és az összetettség növekedésével váltson különálló adattárakra.

Adattár és projektigazítási stratégia

Egyetlen projekt több adattárral:

Legjobb a következőhöz: Termékek és szolgáltatások összehangolt kiadási ütemezéssel
Előnyök: Megosztott folyamatok, konzisztens hozzáférés-vezérlés, egyszerűsített felügyelet
Használat: A fejlesztők gyakran dolgoznak több adattáron, és konzisztens eszközhasználatot igényelnek

Több, dedikált adattárral rendelkező projekt:

Legjobban a következő termékekhez használható: Független ütemezéssel vagy eltérő követelményekkel rendelkező termékek
Előnyök: Független testreszabás, különálló irányítás, egyértelmű határok

Feljegyzés

A Git-adattár hordozhatósága lehetővé teszi a teljes véglegesítési előzményekkel rendelkező projektek közötti egyszerű migrálást.

Az adattárak szervezetének döntési tényezői:

Kódfüggőségek: Önállóan üzembe helyezhető termékek és szolgáltatások elhelyezése külön adattárakban
Koordinációs igények: A kapcsolódó kódbázisok együtt tartása, ha összehangolt változások várhatók
Architektúra: Meglévő monolitok karbantartása egyetlen adattárban; leválasztott szolgáltatások elkülönítése
Csoporthozzáférés: Megfelelő engedélykezelés implementálása az adattár létrehozásának szabályozásához

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

Használjon megosztott adattárat egy megbízható szervezeten belül. A fejlesztők ágak használatával távol tartják egymástól a módosításokat. A jó elágaztatási és kiadási stratégiával egyetlen adattár 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 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, 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 fenntartania egy külön projektet, amely elkülöníti az elágazott adattárakat a fő adattártól. További adminisztrációs többletterhelések vannak, 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 vállalata a szervezeteit, projektjeit, munkaelemeit, csapatait és adattárait.

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

Ideiglenes és megosztott erőforrások kezelése

Fontolja meg, hogyan kezelheti hatékonyan az ideiglenes és megosztott erőforrásokat az alábbi ajánlott eljárások használatával:

Ideiglenes környezetek: Az ideiglenes környezetek rövid élettartamúak, és olyan feladatokhoz használhatók, mint a tesztelés, a fejlesztés vagy az előkészítés. A környezetek hatékony kezelése:
- Különálló adattárak és folyamatok: Minden egyes ideiglenes környezetnek és a hozzá tartozó erőforrásoknak, például az Azure Functionsnek saját adattárral és folyamatokkal kell rendelkezniük. Ez az elkülönítés azt jelenti, hogy egyszerre telepítheti és visszaállíthatja a környezetet annak erőforrásaival együtt. Egyszerűbb felpörgetni és szükség szerint elvetni őket.
- Példa: Hozzon létre egy adattárat és folyamatot kifejezetten a fejlesztési környezethez, beleértve az összes szükséges erőforrást, például az Azure Functionst, a tárfiókokat és más szolgáltatásokat.
Megosztott erőforrások: A megosztott erőforrások általában hosszú élettartamúak, és több környezetben használják. Ezeknek az erőforrásoknak gyakran hosszabb a felfutási ideje és magasabb a költsége. Megosztott erőforrások hatékony kezelése:
- Különálló adattárak és folyamatok: A megosztott erőforrásoknak, például az Azure SQL Database-nek saját adattárral és folyamatokkal kell rendelkezniük. Ez az elkülönítés biztosítja, hogy az ideiglenes környezetek megosztott erőforrásokat használhassanak, így telepítések gyorsabban és költséghatékonyabban valósulnak meg.
- Példa: Hozzon létre egy adattárat és folyamatot az Azure SQL Database-hez, amelyet több ideiglenes környezet is használhat.
Megosztott infrastruktúra erőforrásai: A megosztott infrastruktúra-erőforrásoknak, például a virtuális magánfelhőknek és az alhálózatoknak, más néven célzónáknak is saját adattárakkal és folyamatokkal kell rendelkezniük. Ez a megközelítés gondoskodik arról, hogy az infrastruktúrát következetesen kezelje, és a különböző környezetekben újra felhasználhatja.
- Példa: Hozzon létre egy adattárat és folyamatot a VPC és az alhálózat konfigurációjához, amelyre más adattárak és folyamatok hivatkozhatnak.

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ók vagy Microsoft Entra-példány használatával. 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 hitelesítenie a felhasználókat egy szervezetnél a Microsoft Entra-azonosító használatával. 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.

Egy nagyobb vállalat esetében 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-Mérnöki
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.