Udostępnij przez

Planowanie struktury organizacyjnej

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

Użyj struktury biznesowej jako przewodnika dotyczącego liczby organizacji, projektów i zespołów tworzonych w usłudze Azure DevOps. Ten kompleksowy przewodnik planowania ułatwia projektowanie optymalnych struktur organizacyjnych, które dostosowują przepływy pracy deweloperskie do celów biznesowych.

Strategiczne ramy planowania

Podstawowe decyzje dotyczące struktury

Rozwiąż następujące podstawowe pytania, aby kierować strukturą usługi Azure DevOps:

Poziom organizacyjny:

Poziom projektu:

Poziom zespołu i repozytorium:

Zagadnienia pomocnicze

  • Zarządzanie dostępem: Definiowanie, kto potrzebuje dostępu do jakich informacji i zasobów
  • Wymagania dotyczące raportowania: Planowanie widoczności między zespołami i zarządzania portfelem
  • Standaryzacja procesów: podwyższanie poziomu spójnych praktyk przy jednoczesnym umożliwieniu elastyczności zespołu
  • Dopasowanie kulturowe: wspieranie elastycznego myślenia i kultury współpracy

Napiwek

Zacznij od prostszych struktur i rozwijaj się w miarę rozwoju organizacji. Łatwiej jest podzielić duży projekt niż scalić oddzielne organizacje.

Omówienie organizacji usługi Azure DevOps

Organizacja w usłudze Azure DevOps służy jako kontener najwyższego poziomu dla projektów, zapewniając rozliczenia, zabezpieczenia i granice administracyjne. Organizacje umożliwiają:

  • Scentralizowanie rozliczeń i licencjonowania w powiązanych projektach i zespołach
  • Ustanawianie granic zabezpieczeń z różnymi mechanizmami kontroli dostępu i zasadami
  • Zapewnianie izolacji administracyjnej dla różnych jednostek biznesowych lub wymagań dotyczących zgodności
  • Nawiązywanie połączenia z dostawcami tożsamości , takimi jak Microsoft Entra ID na potrzeby ujednoliconego uwierzytelniania

Korzyści organizacji i darmowy poziom

Każda organizacja obejmuje usługi w warstwie bezpłatnej dla maksymalnie pięciu użytkowników.

Usługa Korzyści Poziomu Bezpłatnego
Azure Pipelines Jedno zadanie hostowane w chmurze z 1800 minutami miesięcznie dla CI/CD oraz jedno zadanie samodzielnie hostowane
Azure Boards Śledzenie elementów roboczych i tablice Kanban na potrzeby zarządzania projektami
Azure Repos Nieograniczone prywatne repozytoria Git na potrzeby kontroli źródła
Azure Artifacts Zarządzanie pakietami dla zależności i artefaktów kompilacji
Dostęp uczestników projektu Nieograniczona liczba interesariuszy do wyświetlania i podstawowego uczestnictwa 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.

Typowe wzorce organizacji:

  • Jedna organizacja: większość firm korzysta z jednej organizacji na potrzeby ujednoliconej współpracy
  • Organizacje jednostek biznesowych: oddzielne organizacje pod kątem odrębnych wymagań dotyczących zgodności lub zabezpieczeń
  • Organizacje geograficzne: Regionalna separacja miejsca przechowywania danych lub lokalnego ładu

Ile organizacji potrzebujesz?

Zacznij od jednej organizacji i rozwiń tylko wtedy, gdy masz określone wymagania biznesowe, które wymagają rozdzielenia.

Kryteria decyzyjne dla wielu organizacji

Utwórz więcej organizacji, gdy potrzebujesz:

Separacja zabezpieczeń i zgodności:

  • Różne wymagania prawne (SOX, HIPAA, PCI-DSS)
  • Odrębne wymagania dotyczące izolacji danych klientów
  • Oddzielne dzienniki inspekcji i raportowanie zgodności

Wymagania dotyczące struktury biznesowej:

  • Niezależne jednostki biznesowe z oddzielnym ładem IT
  • Różne wymagania dotyczące rozliczeń i centrum kosztów
  • Różne połączenia dostawcy tożsamości (różne dzierżawy firmy Microsoft)

Granice administracyjne:

  • Różne grupy administratorów bez nakładania się
  • Oddzielanie zasad i kontrolek organizacyjnych
  • Niezależne umowy dotyczące poziomu usług

Ramy ewaluacyjne

Czynnik Pojedyncza organizacja Wiele organizacji
Współpraca Maksymalna widoczność i udostępnianie Izolowane, ograniczone współużytkowanie między organizacjami
Administracja Scentralizowane, prostsze zarządzanie Rozproszona, większe nakłady pracy administracyjnej
Raportowanie Ujednolicone panele kontrolne i analizy Oddzielne systemy raportowania
Cost Pojedyncza jednostka rozliczeniowa Wiele jednostek rozliczeniowych
Bezpieczeństwo Granice wspólne, ujednolicone zasady Twarde granice, niezależne zasady

Ważne

W przypadku firmowych organizacji firmy Microsoft Entra rozważ ograniczenie tworzenia organizacji w celu ochrony własności intelektualnej i utrzymania ładu.

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.

Opis projektów

Projekty zapewniają kontener do pracy programistycznej zawierającej następujące zintegrowane usługi:

  • Azure Boards: planowanie agile z listami zaległości, przebiegami i śledzeniem elementów roboczych
  • Azure Pipelines: ciągła integracja i automatyzacja wdrażania
  • Azure Repos: repozytoria Git lub TFVC na potrzeby zarządzania kodem źródłowym
  • Plany testów platformy Azure: integracja ręcznego i zautomatyzowanego testowania
  • Zasoby udostępnione: witryna typu wiki, pulpity nawigacyjne i ustawienia na poziomie projektu

W poniższym przykładzie firma Contoso Manufacturing używa czterech projektów do organizowania różnych linii produktów:

Diagram organizacji z czterema projektami.

Korzyści i zagadnienia dotyczące projektu

Projekty są włączone:

  • Udostępnione harmonogramy iteracji i taksonomia między zespołami
  • Spójne szablony procesów i typy elementów roboczych
  • Zintegrowane raportowanie i zarządzanie portfelem
  • Uproszczone zarządzanie użytkownikami i kontrola dostępu

Projekty zapewniają granice dla:

  • Uprawnienia zabezpieczeń i dostępu
  • Dostosowywanie procesów i śledzenie pracy
  • Zasady administracyjne i nadzór
  • Alokacja zasobów i śledzenie rozliczeń

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żytkownicyProject-Scoped nie mogą uzyskiwać dostępu do projektów, do których nie są dodawani. 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.

Struktura decyzyjna projektu

Wybierz odpowiednią strukturę projektu na podstawie potrzeb współpracy:

Podejście do pojedynczego projektu:

  • Najlepsze dla: Mniejsze organizacje lub zespoły z ścisłą współpracą
  • Korzyści: maksymalna widoczność, udostępnione zasoby, ujednolicone raportowanie
  • Rozważ, kiedy: zespoły pracują nad powiązanymi produktami z podobnymi cyklami wydawania

Podejście do wielu projektów:

  • Najlepsze dla: Niezależne zespoły z różnymi wymaganiami
  • Korzyści: Lepsze granice zabezpieczeń, procesy dostosowywalne, autonomia zespołu
  • Rozważ, kiedy: różne potrzeby zgodności lub oddzielne jednostki biznesowe

Usługa Azure DevOps zapewnia funkcje międzyprojektowe do zarządzania pracą w wielu projektach.

Rozważ wiele projektów dla:

  • Ograniczanie dostępu do określonych informacji lub zarządzanie nim
  • Obsługa niestandardowych procesów śledzenia pracy dla różnych jednostek biznesowych
  • Obsługa oddzielnych jednostek biznesowych z niezależnymi zasadami administracyjnymi
  • Testowanie dostosowań lub rozszerzeń przed wdrożeniem produkcyjnym

Ważne

Przenośność repozytorium Git umożliwia łatwą migrację repozytoriów (w tym pełnej historii) między projektami. Jednak nie można migrować innych historii, takich jak push i pull requests między projektami.

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 danej lokalizacji geograficznej (na przykład w Europie). 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 migracji starszych systemów i dla sztywnych granic bezpieczeństwa 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.

Strategia repozytorium i kontrola wersji

Skonfiguruj strategię repozytorium na podstawie rozmiaru zespołu, architektury produktu i wymagań dotyczących wdrażania.

Wybór systemu kontroli wersji

Wybierz pomiędzy Git a Team Foundation Version Control (TFVC):

Repozytoria Git:

  • Zalecane podejście do nowoczesnych przepływów pracy deweloperskich
  • Nieograniczone repozytoria na projekt
  • Rozproszona kontrola wersji z elastycznym rozgałęzianiem
  • Integruje się z większością narzędzi deweloperskich oraz systemów CI/CD

Kontrola wersji programu Team Foundation (TFVC):

  • Scentralizowany system kontroli wersji
  • Pojedyncze repozytorium na projekt z organizacją opartą na folderach
  • Odpowiednie dla zespołów preferujących scentralizowane przepływy pracy

Napiwek

Projekty mogą używać zarówno repozytoriów Git, jak i TFVC, jeśli zespoły mają różne preferencje przepływu pracy.

Wzorce organizacji repozytorium

Strategia monorepo:

  • Najlepsze dla: Małe zespoły nabierające rozpędu wraz z powiązanymi usługami
  • Korzyści: uproszczone udostępnianie i skoordynowane zmiany
  • Wyzwania: Złożoność wiedzy zwiększa się wraz ze wzrostem zespołu; nieintendowane sprzężenie usług; trudne śledzenie zmian

Strategia oddzielnych repozytoriów:

  • Najlepsze rozwiązanie: większe zespoły z niezależnymi wdrożeniami usług
  • Korzyści: Jasne granice usług, łatwiejsze wdrożenie, niezależne cykle wydawania
  • Zagadnienia: wymaga bardziej początkowej konfiguracji, ale efektywnie skaluje się wraz ze wzrostem zespołu

Napiwek

Zacznij od monorepo dla małych zespołów i przejdź do oddzielnych repozytoriów, gdy twoja organizacja rośnie i zwiększa się złożoność.

Strategia dopasowania repozytorium i projektu

Pojedynczy projekt z wieloma repozytoriami:

  • Najlepsze dla: Produkty/usługi z skoordynowanymi harmonogramami wydań
  • Korzyści: Współużytkowane procesy, spójne mechanizmy kontroli dostępu, usprawniona administracja
  • Używaj, gdy: Deweloperzy często pracują w wielu repozytoriach i wymagają spójnych narzędzi

Wiele projektów z dedykowanymi repozytoriami:

  • Najlepsze dla: Produkty z niezależnymi harmonogramami lub odrębnymi wymaganiami
  • Korzyści: Niezależne dostosowywanie, oddzielne zarządzanie, jasne granice

Uwaga

Przenośność repozytorium Git umożliwia łatwą migrację między projektami z pełną historią zatwierdzania.

Czynniki decyzyjne dla organizacji repozytorium:

  • Zależności kodu: umieszczanie niezależnie wdrażanych produktów/usług w oddzielnych repozytoriach
  • Potrzeby koordynacji: zachowaj powiązane bazy kodu razem, gdy oczekiwane są skoordynowane zmiany
  • Architektura: utrzymanie istniejących monolitów w pojedynczych repozytoriach; separacja rozłączonych usług
  • Dostęp zespołowy: Implementowanie odpowiedniego zarządzania uprawnieniami w celu kontrolowania tworzenia repozytorium

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 warto zachować oddzielny projekt, aby odizolować rozwidlone repozytoria od repozytorium głównego. Może występować dodatkowe obciążenie administracyjne, ale utrzymuje główny projekt bardziej przejrzysty. 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.

Treści powiązane

  • Last updated on