Udostępnij za pośrednictwem

Planowanie struktury organizacyjnej

  • Artykuł

Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019

Użyj struktury biznesowej jako przewodnika dotyczącego liczby organizacji, projektów i zespołów tworzonych w usłudze Azure DevOps. Ten artykuł ułatwia planowanie różnych struktur i scenariuszy dla usługi Azure DevOps.

Rozważ następujące struktury dla twojej firmy i współpracy w usłudze Azure DevOps:

Możesz również zaplanować następujące scenariusze:

Mieć co najmniej jedną organizację, która może reprezentować Twoją firmę, większą kolekcję projektów kodu, a nawet wiele powiązanych jednostek biznesowych.

Co to jest organizacja?

Organizacja w usłudze Azure DevOps to mechanizm organizowania i łączenia grup powiązanych projektów. Przykłady obejmują działy biznesowe, podziały regionalne lub inne struktury przedsiębiorstwa. Możesz wybrać jedną organizację dla całej firmy, jedną organizację dla siebie lub oddzielne organizacje dla określonych jednostek biznesowych.

Każda organizacja otrzymuje własną bezpłatną warstwę usług (do pięciu użytkowników dla każdego typu usługi) w następujący sposób. Możesz użyć wszystkich usług lub wybrać tylko to, czego potrzebujesz, aby uzupełnić istniejące przepływy pracy.

  • Azure Pipelines: jedno hostowane zadanie z 1800 minutami miesięcznie dla ciągłej integracji/ciągłego wdrażania i jedno zadanie hostowane samodzielnie
  • Azure Boards: śledzenie elementów roboczych i tablice
  • Azure Repos: nieograniczone prywatne repozytoria Git
  • Azure Artifacts: zarządzanie pakietami
  • Nieograniczone osoby biorące udział w projekcie
    • Pierwszych pięciu użytkowników bezpłatnie (licencja podstawowa)
    • Azure Pipelines
      • Jedna ciągła integracja/ciągłe wdrażanie (jedno współbieżne zadanie, do 30 godzin miesięcznie)
      • Jedno współbieżne zadanie ciągłej integracji/ciągłego wdrażania
    • Azure Boards: śledzenie elementów roboczych i tablice
    • Azure Repos: nieograniczone prywatne repozytoria Git
    • Azure Artifacts: dwie bezpłatne gib na organizację

Uwaga

Usługa testowania obciążenia opartego na chmurze usługi Azure DevOps jest przestarzała, ale testowanie obciążenia platformy Azure pozostaje dostępne. Ta w pełni zarządzana usługa testowania obciążenia umożliwia generowanie obciążenia na dużą skalę przy użyciu istniejących skryptów apache JMeter. Aby uzyskać więcej informacji, zobacz Co to jest testowanie obciążenia platformy Azure? i Zmiany funkcji testowania obciążenia w programie Visual Studio i testowaniu obciążenia w chmurze w usłudze Azure DevOps.

Ile organizacji potrzebujesz?

Zacznij od jednej organizacji w usłudze Azure DevOps. Następnie możesz dodać więcej organizacji , które mogą wymagać różnych modeli zabezpieczeń — później. Jedno repozytorium kodu lub projekt potrzebuje tylko jednej organizacji. Jeśli masz oddzielne zespoły, które muszą pracować nad kodem lub innymi projektami w izolacji, rozważ utworzenie oddzielnych organizacji dla tych zespołów. Będą one miały różne adresy URL. Dodaj projekty, zespoły i repozytoria w razie potrzeby przed dodaniem innej organizacji.

Pośmiń trochę czasu, aby przejrzeć strukturę pracy oraz różne grupy biznesowe i uczestników, które mają być zarządzane. Aby uzyskać więcej informacji, zobacz Mapuj projekty na jednostki biznesowe i Zagadnienia dotyczące struktury.

Napiwek

W przypadku firmowych organizacji firmy Microsoft Entra należy rozważyć ograniczenie użytkowników do tworzenia nowych organizacji jako sposobu ochrony twojego adresu IP. Aby uzyskać więcej informacji, zobacz Ograniczanie tworzenia organizacji za pośrednictwem zasad dzierżawy firmy Microsoft Entra. Użytkownicy mogą tworzyć organizacje przy użyciu kont MSA lub GitHub bez ograniczeń.

Co to jest zespół?

Zespół jest jednostką, która obsługuje wiele narzędzi konfigurowalnych przez zespół. Te narzędzia ułatwiają planowanie pracy i zarządzanie nią oraz ułatwiają współpracę.

Tworzenie zespołu dla każdego odrębnego zespołu produktu lub funkcji

Każdy zespół jest właścicielem własnej listy prac. Aby utworzyć nową listę prac, należy utworzyć nowy zespół. Skonfiguruj zespoły i listy prac w strukturze hierarchicznej, aby właściciele programów mogli łatwiej śledzić postęp w zespołach, zarządzać portfelami i generować dane zestawienia. Grupa zespołu jest tworzona podczas tworzenia zespołu. Możesz użyć tej grupy w zapytaniach lub ustawić uprawnienia dla zespołu.

Co to jest projekt?

Projekt w usłudze Azure DevOps zawiera następujący zestaw funkcji:

  • Tablice i listy prac na potrzeby planowania elastycznego
  • Potoki na potrzeby ciągłej integracji i wdrażania
  • Repozytoria na potrzeby kontroli wersji i zarządzania kodem źródłowym i artefaktami
  • Ciągła integracja testów w całym cyklu życia projektu Każda organizacja zawiera co najmniej jeden projekt

Na poniższej ilustracji fikcyjna firma Contoso ma cztery projekty w organizacji Contoso-Manufacturing.

Obraz organizacji z czterema projektami

Ile projektów potrzebujesz?

Masz co najmniej jeden projekt, aby rozpocząć korzystanie z usługi Azure DevOps, takiej jak Azure Boards, Azure Repos lub Azure Pipelines. Podczas tworzenia organizacji zostanie utworzony domyślny projekt. W projekcie domyślnym istnieje repozytorium kodu do rozpoczęcia pracy, listy prac w celu śledzenia pracy i co najmniej jednego potoku w celu rozpoczęcia automatyzacji kompilacji i wydania.

W organizacji można wykonać jedną z następujących metod:

  • Tworzenie pojedynczego projektu zawierającego wiele repozytoriów i zespołów
  • Tworzenie wielu projektów, z których każdy ma własny zestaw zespołów, repozytoriów, kompilacji, elementów roboczych i innych elementów

Nawet jeśli masz wiele zespołów pracujących nad setkami różnych aplikacji i projektów oprogramowania, możesz zarządzać nimi w ramach jednego projektu w usłudze Azure DevOps. Jeśli jednak chcesz zarządzać bardziej szczegółowymi zabezpieczeniami między projektami oprogramowania i ich zespołami, rozważ użycie wielu projektów. Na najwyższym poziomie izolacji jest organizacja, w której każda organizacja jest połączona z jedną dzierżawą firmy Microsoft Entra. Jednak pojedyncza dzierżawa firmy Microsoft Entra może być połączona z wieloma organizacjami usługi Azure DevOps.

Uwaga

Jeśli dla organizacji jest włączona funkcja Ogranicz widoczność użytkownika i współpracę z określonymi projektami w wersji zapoznawczej, użytkownicy dodani do grupy Użytkownicy o zakresie projektu nie będą mogli uzyskiwać dostępu do projektów, do których nie zostały dodane. Aby uzyskać więcej informacji i ważnych objaśnień związanych z zabezpieczeniami, zobacz Zarządzanie organizacją, Ograniczanie widoczności użytkowników dla projektów i nie tylko.

Pojedynczy projekt

Pojedynczy projekt stawia całą pracę na tym samym poziomie "portfolio" dla całej organizacji. Praca ma ten sam zestaw ścieżek repozytoriów i iteracji. W przypadku pojedynczego projektu zespoły udostępniają repozytoria źródłowe, definicje kompilacji, definicje wersji, raporty i źródła pakietów. Może istnieć duży produkt lub usługa zarządzana przez wiele zespołów. Te zespoły mają ścisłe zależności między cyklem życia produktu. Projekt można utworzyć i podzielić pracę przy użyciu zespołów i ścieżek obszaru. Ta konfiguracja zapewnia zespołom wgląd w pracę nawzajem, dzięki czemu organizacja pozostaje zgodna. Zespoły używają tej samej taksonomii do śledzenia elementów roboczych, co ułatwia komunikację i spójność.

Napiwek

Gdy wiele zespołów pracuje nad tym samym produktem, posiadanie wszystkich zespołów w tym samym harmonogramie iteracji pomaga zachować dopasowanie zespołów i dostarczanie wartości w tym samym czasie. Na przykład nasza organizacja w usłudze Azure DevOps ma ponad 40 zespołów funkcji i 500 użytkowników w ramach jednego projektu — działa to dobrze, ponieważ wszyscy pracujemy nad wspólnym zestawem produktów z typowymi celami i wspólnym harmonogramem wydania.

Duża liczba zapytań i tablic może utrudnić znalezienie szukanych elementów. W zależności od architektury produktu ten problem może być podzielony na inne obszary, takie jak kompilacje, wydania i repozytoria. Pamiętaj, aby używać dobrych konwencji nazewnictwa i prostej struktury folderów. Po dodaniu repozytorium do projektu rozważ strategię i określ, czy to repozytorium może zostać umieszczone we własnym projekcie.

Wiele projektów

Możesz najlepiej określić strukturę projektu, wysyłając produkt. Posiadanie kilku projektów zmienia obciążenie administracyjne i zapewnia zespołom większą autonomię zarządzania projektem, gdy zespół decyduje. Zapewnia również większą kontrolę nad zabezpieczeniami i dostępem do zasobów w różnych projektach. Posiadanie niezależności zespołu w wielu projektach stwarza jednak pewne wyzwania wyrównania. Jeśli każdy projekt korzysta z innego procesu lub harmonogramu iteracji, może utrudnić komunikację i współpracę, jeśli taksonomie nie są takie same.

Napiwek

Jeśli używasz tego samego procesu i harmonogramów iteracji we wszystkich projektach, możliwość tworzenia zbiorczych danych i raportów między zespołami się poprawia.

Usługa Azure DevOps zapewnia środowiska między projektami na potrzeby zarządzania pracą.

Możesz dodać inny projekt ze względu na następujące scenariusze:

  • Aby uniemożliwić dostęp do informacji w projekcie lub zarządzać nim
  • Obsługa niestandardowych procesów śledzenia pracy dla określonych jednostek biznesowych w organizacji
  • Aby obsługiwać całkowicie oddzielne jednostki biznesowe, które mają własne zasady administracyjne i administratorów
  • Aby umożliwić testowanie działań dostosowywania lub dodawanie rozszerzeń przed wprowadzeniem zmian w projekcie roboczym

Podczas rozważania wielu projektów należy pamiętać, że przenośność repozytoriów Git ułatwia migrowanie repozytoriów (w tym pełnej historii) między projektami. Nie można migrować innych historii między projektami. Przykłady to historia wypychania i żądania ściągnięcia.

Podczas mapowania projektów na jednostki biznesowe firma otrzymuje jedną organizację i konfiguruje wiele projektów z co najmniej jednym projektem reprezentującym jednostkę biznesową. Wszystkie zasoby usługi Azure DevOps firmy znajdują się w tej organizacji i znajdują się w danym regionie (na przykład w Europie Zachodniej). Rozważ następujące wskazówki dotyczące mapowania projektów na jednostki biznesowe:

Jeden projekt, wiele zespołów Jedna organizacja, wiele projektów i zespołów Wiele organizacji
Wskazówki ogólne Najlepsze dla mniejszych organizacji lub większych organizacji z wysoce dopasowanymi zespołami. Dobra, gdy różne działania wymagają różnych procesów. Przydatne w ramach starszych migracji serwera TFS i dla twardych granic zabezpieczeń między organizacjami. Używany z wieloma projektami i zespołami w każdej organizacji.
Skaluj Obsługuje dziesiątki tysięcy użytkowników i setki zespołów, ale najlepiej na tej skali, jeśli wszystkie zespoły pracują nad powiązanymi wysiłkami. Podobnie jak w przypadku jednego projektu, ale wiele projektów może być łatwiejszych.
Proces Dopasowane procesy między zespołami; elastyczność zespołu w zakresie dostosowywania tablic, pulpitów nawigacyjnych itd. Niezależne procesy dla każdego projektu. Na przykład różne typy elementów roboczych, pola niestandardowe itd. Tak samo jak wiele projektów.
Współpraca Najwyższa domyślna widoczność i ponowne użycie między pracą a elementami zawartości różnych zespołów. Istnieje możliwość dobrego wglądu i ponownego użycia, ale łatwiej jest ukryć zasoby między projektami, czy są zamierzone. Słaba widoczność, współpraca i ponowne użycie między organizacjami.
Zbiorcze raportowanie i zarządzanie portfelem Najlepsza zdolność do wprowadzania w zespołach i koordynowania między zespołami. Dobre raportowanie możliwe w projektach. Trudniejsze w przypadku rzutowania między projektami i koordynacji zespołu. Brak zestawienia ani koordynacji między organizacjami.
Zabezpieczenia/izolacja Może zablokować zasoby na poziomie zespołu, ale ustawienie domyślne to otwarta widoczność i współpraca. Lepsza zdolność do blokowania między projektami. Domyślnie zapewnia dobry wgląd w projekty i dobrą izolację między projektami. Twarde granice między organizacjami; doskonała izolacja i minimalna możliwość udostępniania w organizacjach.
Przełączanie kontekstu Najprostszym rozwiązaniem jest współpraca zespołów i przełączanie się między wysiłkami użytkowników. Stosunkowo łatwe dla użytkowników do współpracy i przełączania kontekstów między wysiłkami. Trudniejsze dla użytkowników, którzy muszą pracować w różnych organizacjach.
Przeciążenie informacji Domyślnie wszystkie zasoby są widoczne dla użytkowników korzystających z "ulubionych" i podobnych mechanizmów, aby uniknąć "przeciążenia informacji". Zmniejszenie ryzyka przeciążenia informacji; większość zasobów projektu ukrytych w granicach projektu. Zasoby w różnych organizacjach są izolowane, co zmniejsza ryzyko przeciążenia informacji.
Koszty administracyjne Wiele administracji jest delegowanych do poszczególnych zespołów. Najłatwiejsze w przypadku licencjonowania użytkowników i administracji na poziomie organizacji. W przypadku konieczności dostosowania między wysiłkami może być wymagana większa praca. Więcej administracji na poziomie projektu. Większe obciążenie, ale może być przydatne, gdy projekty mają różne potrzeby administracyjne. Podobnie jak w przypadku większej liczby projektów, istnieje więcej obciążeń administracyjnych, co zapewnia większą elastyczność między organizacji.

Repozytoria struktury i kontrola wersji w projekcie

Rozważ określoną pracę strategiczną w zakresie jednej z utworzonych wcześniej organizacji i osób, które potrzebują dostępu. Użyj tych informacji, aby nazwać i utworzyć projekt. Ten projekt ma adres URL zdefiniowany w organizacji, w której został utworzony i można uzyskać do niego dostęp pod adresem https://dev.azure.com/{organization-name}/{project-name}.

Skonfiguruj projekt w ustawieniach projektu.

Zrzut ekranu przedstawiający przycisk Ustawienia projektu.

Aby uzyskać więcej informacji na temat zarządzania projektami, zobacz Zarządzanie projektami w usłudze Azure DevOps. Projekt można przenieść do innej organizacji, migrując dane. Aby uzyskać więcej informacji na temat migrowania projektu, zobacz Omówienie migracji.

Zarządzanie kontrolą wersji

W projektach, w których włączono usługę Azure Repos, repozytoria kontroli wersji mogą przechowywać i poprawiać kod. Podczas konfigurowania repozytoriów należy wziąć pod uwagę następujące opcje.

Git a Kontrola wersji serwera Team Foundation (TFVC)

Usługa Azure Repos oferuje następujące systemy kontroli wersji dla zespołów do wyboru:

  • Git i TFVC. Projekty mogą mieć repozytoria każdego typu. Domyślnie nowe projekty mają puste repozytorium Git. Usługa Git zapewnia dużą elastyczność w przepływach pracy deweloperów i integruje się z niemal każdym odpowiednim narzędziem w ekosystemie deweloperów. Każdy projekt może używać repozytoriów Git. Nie ma limitu ilości repozytoriów Git, które można dodać do projektu.

TfVC to scentralizowany system kontroli wersji, który jest również dostępny. W przeciwieństwie do usługi Git tylko jedno repozytorium TFVC jest dozwolone dla projektu. Jednak w tym repozytorium foldery i gałęzie są używane do organizowania kodu dla wielu produktów i usług, jeśli jest to konieczne. W razie potrzeby projekty mogą używać kontroli wersji serwera Team Foundation i usługi Git.

Monorepo a jedno repozytorium na usługę

Wdrażanie różnych niezależnych usług z monorepo może być skuteczne dla małych zespołów mających na celu budowanie wczesnego tempa. Jednak ta strategia może stać się problematyczna w miarę rozwoju zespołu z powodu kilku czynników:

  • Wiedza wymagana dla nowych członków zwiększa się wraz z ogólną złożonością systemu.
  • Udostępnianie kodu w jednym repozytorium może spowodować niezamierzone sprzężenie między usługami.
  • Zmiany w kodzie udostępnionym mogą mieć wpływ na zachowanie różnych usług, co utrudnia śledzenie tych zmian.

W przypadku większych zespołów zarządzanie monorepo wymaga silnej dyscypliny inżynieryjnej i niezawodnych narzędzi. Alternatywnie możesz wybrać poszczególne repozytoria dla każdej usługi wraz z oddzielnym repozytorium dla zasobów udostępnionych. Mimo że takie podejście wiąże się z bardziej początkową konfiguracją, zwiększa się w miarę zwiększania się zespołu. Ułatwia również dołączanie nowych członków, którzy mogą skoncentrować się wyłącznie na ich konkretnym repozytorium usług.

Jeśli zaczynasz od małego zespołu, monorepo może być dobrym wyborem. Wraz ze wzrostem złożoności zespołu można przejść do oddzielnych repozytoriów.

Jeden z wielu repozytoriów w projekcie

Czy musisz skonfigurować wiele repozytoriów w jednym projekcie lub skonfigurować repozytorium dla każdego projektu? Poniższe wskazówki odnoszą się do funkcji planowania i administrowania w tych repozytoriach.

Jeden projekt zawierający wiele repozytoriów działa dobrze, jeśli produkty/usługi pracują zgodnie z skoordynowanym harmonogramem wydania. Jeśli deweloperzy często pracują z wieloma repozytoriami, zachowaj je w jednym projekcie, aby upewnić się, że procesy pozostaną współużytkowane i spójne. Łatwiej jest zarządzać dostępem do repozytorium w ramach jednego projektu, ponieważ mechanizmy kontroli dostępu i opcje, takie jak wymuszanie wielkości liter i maksymalny rozmiar pliku, są ustawiane na poziomie projektu. Kontrolę dostępu i ustawienia można zarządzać indywidualnie, nawet jeśli repozytoria znajdują się w jednym projekcie.

Jeśli produkty przechowywane w wielu repozytoriach działają zgodnie z niezależnymi harmonogramami lub procesami, możesz podzielić je na wiele projektów. Przenośność repozytorium Git ułatwia przenoszenie repozytorium między projektami i zachowanie pełnej wierności historii zatwierdzeń. Inna historia, taka jak żądania ściągnięcia lub historia kompilacji, nie jest łatwo migrowana.

Na podstawie decyzji o jednej z wielu repozytoriów należy opierać się na następujących czynnikach i wskazówkach:

  • Zależności i architektura kodu
  • Umieść każdy niezależnie wdróż produkt lub usługę we własnym repozytorium
  • Nie rozdzielaj bazy kodu na wiele repozytoriów, jeśli spodziewasz się wprowadzenia skoordynowanych zmian kodu w tych repozytoriach, ponieważ żadne narzędzia nie mogą pomóc w koordynowaniu tych zmian
  • Jeśli baza kodu jest już monolitem, zachowaj ją w jednym repozytorium. Aby uzyskać więcej informacji na temat monolitycznych repozytoriów, zobacz artykuły Jak firma Microsoft opracowuje nowoczesne oprogramowanie za pomocą metodyki DevOps
  • Jeśli masz wiele rozłączonych usług, jedno repozytorium na usługę jest dobrą strategią

Napiwek

Rozważ zarządzanie uprawnieniami, więc nie wszyscy w organizacji mogą utworzyć repozytorium. Jeśli masz zbyt wiele repozytoriów, trudno jest śledzić, kto jest właścicielem kodu lub innej zawartości przechowywanej w tych repozytoriach.

Repozytoria udostępnione a rozwidlone repozytoria

Zalecamy używanie repozytorium udostępnionego w zaufanej organizacji. Deweloperzy używają gałęzi, aby zachować izolację swoich zmian od siebie. Dzięki dobrej strategii rozgałęziania i wydawania pojedyncze repozytorium może być skalowane w celu obsługi współbieżnego programowania dla ponad tysiąca deweloperów. Aby uzyskać więcej informacji na temat rozgałęziania i strategii wydania, zobacz Wdrażanie strategii rozgałęziania Git i Przepływ wydania: nasza strategia rozgałęziania.

Rozwidlenia mogą być przydatne podczas pracy z zespołami dostawców, które nie powinny mieć bezpośredniego dostępu do aktualizowania głównego repozytorium. Rozwidlenia mogą być również przydatne w scenariuszach, w których wielu deweloperów często współtworzy, na przykład w projekcie typu open source. Podczas pracy z rozwidleniami możesz zachować oddzielny projekt, aby odizolować rozwidlone repozytoria od repozytorium głównego. Może istnieć dodatkowe obciążenie administracyjne, ale utrzymuje główny projekt czystszy. Aby uzyskać więcej informacji, zobacz artykuł Forks (Rozwidlenia).

Na poniższej ilustracji przedstawiono przykład sposobu, w jaki "Twoja firma" może strukturę organizacji, projektów, elementów roboczych, zespołów i repozytoriów.

Diagram przedstawiający strukturę organizacyjną firmy.

Zarządzanie zasobami tymczasowymi i udostępnionymi

Rozważ efektywne zarządzanie zasobami tymczasowymi i udostępnionymi, stosując następujące najlepsze rozwiązania:

  • Środowiska tymczasowe: środowiska tymczasowe są krótkotrwałe i używane do wykonywania zadań, takich jak testowanie, programowanie lub przemieszczanie. Aby efektywnie zarządzać tymi środowiskami:
    • Oddzielne repozytoria i potoki: każde środowisko tymczasowe i skojarzone z nim zasoby, na przykład usługa Azure Functions, powinny mieć własne repozytorium i potok. Ta separacja umożliwia jednoczesne wdrażanie i wycofywanie środowiska i jej zasobów, co ułatwia uruchomienie i odrzucenie ich w razie potrzeby.
    • Przykład: utwórz repozytorium i potok specjalnie dla środowiska projektowego, w tym wszystkie niezbędne zasoby, takie jak Azure Functions, konta magazynu i inne usługi.
  • Zasoby udostępnione: Zasoby udostępnione są zwykle długotrwałe i używane w wielu środowiskach. Te zasoby często mają dłuższe czasy uruchamiania i wyższe koszty. Aby efektywnie zarządzać zasobami udostępnionymi:
    • Oddzielne repozytoria i potoki: zasoby udostępnione, takie jak usługa Azure SQL Database, powinny mieć własne repozytorium i potok. To rozdzielenie zapewnia, że środowiska tymczasowe mogą korzystać z tych udostępnionych zasobów, dzięki czemu ich wdrożenia będą szybsze i bardziej ekonomiczne.
    • Przykład: tworzenie repozytorium i potoku dla usługi Azure SQL Database, które może być używane przez wiele środowisk tymczasowych.
  • Udostępnione zasoby infrastruktury: współużytkowane zasoby infrastruktury, takie jak wirtualne chmury prywatne (VPC) i podsieci, znane również jako strefy docelowe, powinny również mieć własne repozytoria i potoki. Takie podejście gwarantuje, że infrastruktura jest zarządzana spójnie i może być ponownie używana w różnych środowiskach.
    • Przykład: utwórz repozytorium i potok dla konfiguracji VPC i podsieci, do którego można odwoływać się przez inne repozytoria i potoki.

Więcej informacji o strukturze organizacyjnej

Wybierz typ konta administratora organizacji

Podczas tworzenia organizacji poświadczenia, które logujesz się przy użyciu definiowania dostawcy tożsamości używanego przez organizację. Utwórz organizację przy użyciu konta Microsoft lub wystąpienia usługi Microsoft Entra. Użyj tych poświadczeń, aby zalogować się jako administrator do nowej organizacji pod adresem https://dev.azure.com/{YourOrganization}.

Korzystanie z konta Microsoft

Użyj konta Microsoft, jeśli nie musisz uwierzytelniać użytkowników w organizacji przy użyciu identyfikatora Entra firmy Microsoft. Wszyscy użytkownicy muszą zalogować się do organizacji przy użyciu konta Microsoft. Jeśli go nie masz, utwórz konto Microsoft.

Wprowadź hasło i zaloguj się

Jeśli nie masz wystąpienia microsoft Entra, utwórz je bezpłatnie w witrynie Azure Portal lub użyj swojego konta Microsoft, aby utworzyć organizację. Następnie możesz połączyć organizację z identyfikatorem Entra firmy Microsoft.

Korzystanie z konta Microsoft Entra

Być może masz już konto Microsoft Entra, jeśli korzystasz z platformy Azure lub platformy Microsoft 365. Jeśli pracujesz w firmie korzystającej z identyfikatora Entra firmy Microsoft do zarządzania uprawnieniami użytkowników, prawdopodobnie masz konto Microsoft Entra.

Jeśli nie masz konta Microsoft Entra, zarejestruj się w usłudze Microsoft Entra ID, aby automatycznie połączyć organizację z identyfikatorem Entra firmy Microsoft. Wszyscy użytkownicy muszą należeć do tego katalogu, aby uzyskać dostęp do organizacji. Aby dodać użytkowników z innych organizacji, użyj funkcji współpracy Microsoft Entra B2B.

Usługa Azure DevOps uwierzytelnia użytkowników za pomocą identyfikatora Entra firmy Microsoft, aby tylko użytkownicy, którzy są członkami tego katalogu, mieli dostęp do organizacji. Po usunięciu użytkowników z tego katalogu nie będą już mogli uzyskać dostępu do organizacji. Tylko konkretni administratorzy firmy Microsoft Entra zarządzają użytkownikami w katalogu, więc administratorzy kontrolują, kto uzyskuje dostęp do organizacji.

Aby uzyskać więcej informacji na temat zarządzania użytkownikami, zobacz Zarządzanie użytkownikami.

Mapuj organizacje na jednostki biznesowe

Każda jednostka biznesowa w firmie uzyskuje własną organizację w usłudze Azure DevOps wraz z własną dzierżawą firmy Microsoft Entra. Projekty można skonfigurować w ramach tych poszczególnych organizacji zgodnie z potrzebami na podstawie zespołów lub trwającej pracy.

W przypadku większej firmy można utworzyć wiele organizacji przy użyciu różnych kont użytkowników (najprawdopodobniej kont Microsoft Entra). Zastanów się, jakie grupy i użytkownicy dzielą się strategiami i działają, i grupuj je w określonych organizacjach.

Na przykład fikcyjna firma Fabrikam utworzyła następujące trzy organizacje:

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

Każda organizacja ma oddzielny adres URL, taki jak:

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

Organizacje są dla tej samej firmy, ale są w większości odizolowane od siebie. Nie musisz oddzielać niczego w ten sposób. Twórz granice tylko wtedy, gdy ma to sens dla Twojej firmy.

Napiwek

Możesz łatwiej podzielić istniejącą organizację na projekty, niż połączyć różne organizacje.