다음을 통해 공유

조직 구조 계획

  • 아티클

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

비즈니스 구조를 Azure DevOps에서 만드는 조직, 프로젝트 및 팀 수에 대한 가이드로 사용합니다. 이 문서는 Azure DevOps에 대한 다양한 구조 및 시나리오를 계획하는 데 도움이 됩니다.

Azure DevOps의 비즈니스 및 공동 작업에 대해 다음 구조를 고려합니다.

다음 시나리오를 계획할 수도 있습니다.

회사, 더 큰 코드 프로젝트 컬렉션 또는 여러 관련 사업부를 나타낼 수 있는 하나 이상의 조직이 있습니다.

조직이란?

Azure DevOps의 조직은 관련 프로젝트 그룹을 구성하고 연결하기 위한 메커니즘입니다. 예를 들어 비즈니스 부서, 지역 부서 또는 기타 엔터프라이즈 구조가 있습니다. 전체 회사에 대해 하나의 조직, 자신을 위한 하나의 조직 또는 특정 사업부에 대한 별도의 조직을 선택할 수 있습니다.

각 조직은 다음과 같이 자체 무료 서비스 계층 (각 서비스 유형에 대해 최대 5명의 사용자)을 가져옵니다. 모든 서비스를 사용하거나 기존 워크플로를 보완하는 데 필요한 것만 선택할 수 있습니다.

  • Azure Pipelines: CI/CD의 경우 매월 1,800분이 있는 호스트된 작업 하나와 자체 호스팅 작업 1개
  • Azure Boards: 작업 항목 추적 및 보드
  • Azure Repos: 무제한 개인 Git 리포지토리
  • Azure Artifacts: 패키지 관리
  • 무제한 이해 관계자
    • 처음 5명의 사용자 무료(기본 라이선스)
    • Azure Pipelines
      • Microsoft에서 호스팅하는 CI/CD 1개(한 동시 작업, 매월 최대 30시간)
      • 자체 호스팅 CI/CD 동시 작업 하나
    • Azure Boards: 작업 항목 추적 및 보드
    • Azure Repos: 무제한 개인 Git 리포지토리
    • Azure Artifacts: 조직당 2GiB 무료

참고 항목

Azure DevOps 클라우드 기반 부하 테스트 서비스는 더 이상 사용되지 않지만 Azure Load Testing 은 계속 사용할 수 있습니다. 이 완전 관리형 부하 테스트 서비스를 사용하면 기존 Apache JMeter 스크립트를 사용하여 대규모 부하를 생성할 수 있습니다. 자세한 내용은 Azure Load Testing이란? 및 Visual Studio의 부하 테스트 기능 및 Azure DevOps의 클라우드 부하 테스트 변경 내용을 참조하세요.

얼마나 많은 조직이 필요한가요?

Azure DevOps에서 하나의 조직으로 시작합니다. 그런 다음 나중에 다른 보안 모델이 필요할 수 있는 더 많은 조직을 추가할 수 있습니다. 단일 코드 리포지토리 또는 프로젝트에는 하나의 조직만 필요합니다. 코드 또는 다른 프로젝트를 격리하여 작업해야 하는 별도의 팀이 있는 경우 해당 팀을 위해 별도의 조직을 만드는 것이 좋습니다. URL이 다릅니다. 다른 조직을 추가하기 전에 필요에 따라 프로젝트, 팀 및 리포지토리를 추가합니다.

작업 구조와 관리할 다양한 비즈니스 그룹 및 참가자를 검토하는 데 시간이 걸릴 수 있습니다. 자세한 내용은 사업부 및 구조 고려 사항에 프로젝트 매핑을 참조하세요.

팁

회사 소유 Microsoft Entra 조직의 경우 IP를 보호하는 방법으로 사용자가 새 조직을 만들지 못하도록 제한하는 것이 좋습니다. 자세한 내용은 Microsoft Entra 테넌트 정책을 통해 조직 만들기 제한을 참조하세요. 사용자는 제한 없이 MSA 또는 GitHub 계정을 사용하여 조직을 만들 수 있습니다.

팀이란?

팀은 여러 팀에서 구성할 수 있는 도구를 지원하는 단위입니다. 이러한 도구를 사용하면 작업을 계획하고 관리하고 공동 작업을 더 쉽게 수행할 수 있습니다.

각 고유 제품 또는 기능 팀에 대한 팀 만들기

각 팀은 자신의 백로그를 소유합니다. 새 백로그를 만들려면 새 팀을 만듭니다. 팀 및 백로그를 계층 구조로 구성하여 프로그램 소유자가 팀 전체의 진행 상황을 보다 쉽게 추적하고, 포트폴리오를 관리하고, 롤업 데이터를 생성할 수 있습니다. 팀을 만들 때 팀 그룹이 만들어집니다. 쿼리에서 이 그룹을 사용하거나 팀에 대한 권한을 설정할 수 있습니다.

프로젝트가란?

Azure DevOps의 프로젝트에는 다음과 같은 기능 집합이 포함되어 있습니다.

  • 민첩한 계획을 위한 보드 및 백로그
  • 연속 통합 및 배포를 위한 파이프라인
  • 소스 코드 및 아티팩트 버전 제어 및 관리를 위한 리포지토리
  • 프로젝트 수명 주기 전체에서 연속 테스트 통합 각 조직에는 하나 이상의 프로젝트가 포함됩니다.

다음 이미지에서 가상의 Contoso 회사에는 Contoso-Manufacturing 조직 내에 4개의 프로젝트가 있습니다.

4개의 프로젝트가 있는 조직의 이미지

필요한 프로젝트는 몇 개입니까?

Azure Boards, Azure Repos 또는 Azure Pipelines와 같은 Azure DevOps 서비스 사용을 시작할 프로젝트가 하나 이상 있어야 합니다. 조직을 만들 때 기본 프로젝트가 만들어집니다. 기본 프로젝트에는 작업을 시작하는 코드 리포지토리, 작업을 추적하는 백로그 및 빌드 및 릴리스 자동화를 시작하기 위한 하나 이상의 파이프라인이 있습니다.

조직 내에서 다음 방법 중 하나를 수행할 수 있습니다.

  • 많은 리포지토리와 팀이 포함된 단일 프로젝트 만들기
  • 각각 고유한 팀, 리포지토리, 빌드, 작업 항목 및 기타 요소 집합을 사용하여 많은 프로젝트를 만듭니다.

수백 개의 다양한 애플리케이션 및 소프트웨어 프로젝트에서 작업하는 팀이 많더라도 Azure DevOps의 단일 프로젝트 내에서 관리할 수 있습니다. 그러나 소프트웨어 프로젝트와 해당 팀 간에 보다 세부적인 보안을 관리하려면 많은 프로젝트를 사용하는 것이 좋습니다. 가장 높은 수준의 격리는 각 조직이 단일 Microsoft Entra 테넌트에 연결된 조직입니다. 그러나 단일 Microsoft Entra 테넌트는 많은 Azure DevOps 조직에 연결할 수 있습니다.

참고 항목

조직에서 특정 프로젝트 미리 보기 기능에 대한 사용자 표시 유형 제한 및 협업을 사용하도록 설정한 경우 프로젝트 범위 사용자 그룹에 추가된 사용자는 추가되지 않은 프로젝트에 액세스할 수 없습니다. 자세한 내용 및 중요한 보안 관련 설명은 조직 관리, 프로젝트에 대한 사용자 표시 제한 등을 참조하세요.

단일 프로젝트

단일 프로젝트는 전체 조직에 대해 모든 작업을 동일한 "포트폴리오" 수준으로 설정합니다. 작업에는 동일한 리포지토리 및 반복 경로 집합이 있습니다. 팀은 단일 프로젝트를 사용하여 원본 리포지토리, 빌드 정의, 릴리스 정의, 보고서 및 패키지 피드를 공유합니다. 많은 팀에서 관리하는 대규모 제품 또는 서비스가 있을 수 있습니다. 이러한 팀은 제품 수명 주기 전반에 걸쳐 긴밀한 종속성을 가지고 있습니다. 프로젝트를 만들고 팀 및 영역 경로를 사용하여 작업을 나눕니다. 이 설정을 통해 팀은 서로의 작업을 파악할 수 있으므로 조직에 정렬된 상태를 유지합니다. 팀은 작업 항목 추적에 동일한 분류를 사용하여 의사 소통을 더 쉽게 하고 일관성을 유지할 수 있습니다.

팁

여러 팀이 동일한 제품에서 작업하는 경우 모든 팀이 동일한 반복 일정에 따라 팀을 정렬하고 동일한 주기로 가치를 제공하는 데 도움이 됩니다. 예를 들어 Azure DevOps의 조직에는 단일 프로젝트 내에 40개 이상의 기능 팀과 500명의 사용자가 있습니다. 이는 모두 공통 목표와 일반적인 릴리스 일정을 사용하여 공통 제품 집합을 작업하고 있기 때문에 잘 작동합니다.

쿼리 및 보드의 양이 많으면 원하는 항목을 찾기가 어려울 수 있습니다. 제품의 아키텍처에 따라 이 난이도는 빌드, 릴리스 및 리포지토리와 같은 다른 영역으로 번질 수 있습니다. 좋은 명명 규칙과 간단한 폴더 구조를 사용해야 합니다. 프로젝트에 리포지토리를 추가할 때 전략을 고려하고 해당 리포지토리를 자체 프로젝트에 배치할 수 있는지 여부를 결정합니다.

많은 프로젝트

제품을 배송하는 방법에 따라 프로젝트 구조를 가장 잘 결정할 수 있습니다. 여러 프로젝트가 있으면 관리 부담이 바뀌고 팀이 결정할 때 프로젝트를 관리할 수 있는 자율성이 팀에 더 많이 부여됩니다. 또한 다양한 프로젝트에서 자산에 대한 보안 및 액세스를 보다 세부적으로 제어할 수 있습니다. 그러나 많은 프로젝트에서 팀 독립성으로 인해 몇 가지 맞춤 문제가 발생합니다. 각 프로젝트가 다른 프로세스 또는 반복 일정을 사용하는 경우 분류가 동일하지 않으면 소통 및 협업이 어려워질 수 있습니다.

팁

모든 프로젝트에서 동일한 프로세스 및 반복 일정을 사용하는 경우 팀 간에 데이터를 롤업하고 보고하는 기능이 향상됩니다.

Azure DevOps는 작업을 관리하기 위한 프로젝트 간 환경을 제공합니다.

다음 시나리오로 인해 다른 프로젝트를 추가할 수 있습니다.

  • 프로젝트 내 정보에 대한 액세스를 금지하거나 관리하려면
  • 조직 내 특정 사업부에 대한 사용자 지정 작업 추적 프로세스를 지원하려면
  • 자체 관리 정책 및 관리자가 있는 완전히 별도의 사업부를 지원하려면
  • 작업 프로젝트에 변경 내용을 롤아웃하기 전에 사용자 지정 작업 테스트 또는 확장 추가를 지원하려면

많은 프로젝트를 고려할 때 Git 리포지토리 이식성을 사용하면 프로젝트 간에 리포지토리(전체 기록 포함)를 쉽게 마이그레이션할 수 있습니다. 프로젝트 간에 다른 기록을 마이그레이션할 수 없습니다. 예를 들어 푸시 및 끌어오기 요청 기록이 있습니다.

프로젝트를 사업부에 매핑하면 회사에서 단일 조직을 가져오고 사업부를 나타내는 하나 이상의 프로젝트로 많은 프로젝트를 설정합니다. 회사의 모든 Azure DevOps 자산은 이 조직 내에 포함되며 지정된 지역(예: 서유럽) 내에 있습니다. 프로젝트를 사업부에 매핑하기 위한 다음 지침을 고려합니다.

하나의 프로젝트, 많은 팀 많은 프로젝트 및 팀이 있는 하나의 조직. 많은 조직
일반 지침 소규모 조직 또는 고도로 정렬된 팀이 있는 대규모 조직에 가장 적합합니다. 다양한 노력에 다른 프로세스가 필요할 때 좋습니다. TFS 레거시 마이그레이션의 일부로 유용하며 조직 간의 하드 보안 경계에 유용합니다. 각 조직 내의 여러 프로젝트 및 팀과 함께 사용됩니다.
규모 수만 명의 사용자와 수백 개의 팀을 지원하지만 모든 팀이 관련 작업을 수행하는 경우 이 규모에서 가장 좋습니다. 하나의 프로젝트와 동일하지만 많은 프로젝트가 더 쉬울 수 있습니다.
처리 팀 전체에서 정렬된 프로세스; 팀 유연성을 통해 보드, 대시보드 등을 사용자 지정할 수 있습니다. 각 프로젝트에 대한 독립적인 프로세스입니다. 예를 들어 작업 항목 유형, 사용자 지정 필드 등이 있습니다. 많은 프로젝트와 동일.
협업 서로 다른 팀의 작업 및 자산 간에 가장 높은 기본 가시성 및 재사용. 가시성이 좋고 재사용이 가능하지만, 의도적이든 아니든 프로젝트 간에 자산을 숨기는 것이 더 쉽습니다. 조직 간의 가시성, 협업 저하 및 재사용 좋지 않음.
롤업 보고 및 포트폴리오 관리 팀 간에 롤업하고 팀 간을 조정할 수 있는 최고의 능력. 프로젝트에서 좋은 보고 가능. 프로젝트 간 롤업 및 팀 조정이 더 어려움. 조직 간에 롤업 또는 조정이 없음.
보안/격리 팀 수준에서 자산을 잠글 수 있지만 기본값은 개방형 표시 유형 및 협업입니다. 프로젝트 간 잠금 기능이 향상되었습니다. 기본적으로 프로젝트 내에서 좋은 가시성을 제공하고 프로젝트 간에 적절한 격리를 제공합니다. 조직 전체의 엄격한 경계, 우수한 격리와 조직 전체에서 공유할 수 있는 최소한의 기능.
컨텍스트 전환 팀이 함께 작업하고 사용자가 작업 간에 전환하는 것이 가장 쉽습니다. 사용자가 함께 작업하고 작업 간에 컨텍스트를 전환하는 것이 비교적 쉽습니다. 사용자가 여러 조직에서 작업해야 하는 경우 더 어렵습니다.
정보 오버로드 기본적으로 모든 자산은 "정보 오버로드"를 방지하기 위해 "즐겨찾기" 및 유사한 메커니즘을 사용하는 사용자에게 표시됩니다. 정보 과부하 위험 감소, 대부분의 프로젝트 자산은 프로젝트 경계를 넘어 숨겨집니다. 조직 전체의 자산이 격리되어 정보 오버로드의 위험을 줄입니다.
관리 오버헤드 많은 관리 작업이 개별 팀에 위임됩니다. 사용자 라이선스 및 조직 수준 관리를 위한 가장 쉬운 기능입니다. 작업 간에 맞춤이 필요한 경우 더 많은 작업이 필요할 수 있습니다. 프로젝트 수준에서 더 많은 관리. 오버헤드가 더 많지만 프로젝트에 관리 요구 사항이 다른 경우에 유용할 수 있습니다. 더 많은 프로젝트와 마찬가지로 더 많은 관리 오버헤드가 있으므로 조직 간의 유연성을 높일 수 있습니다.

프로젝트 내의 구조 리포지토리 및 버전 제어

이전에 만든 조직 중 하나와 액세스가 필요한 조직 중 하나로 범위가 지정된 특정 전략적 작업을 고려합니다. 이 정보를 사용하여 프로젝트의 이름을 지정하고 만듭니다. 이 프로젝트에는 사용자가 만든 조직 아래에 정의된 URL이 있으며 에서 액세스할 수 있습니다. https://dev.azure.com/{organization-name}/{project-name}.

프로젝트 설정에서 프로젝트를 구성합니다.

프로젝트 설정 단추를 보여 주는 스크린샷

프로젝트 관리에 대한 자세한 내용은 Azure DevOps에서 프로젝트 관리를 참조 하세요. 데이터를 마이그레이션하여 프로젝트를 다른 조직으로 이동할 수 있습니다. 프로젝트 마이그레이션에 대한 자세한 내용은 마이그레이션 개요를 참조하세요.

버전 제어 관리

Azure Repos 서비스를 사용하는 프로젝트에서 버전 제어 리포지토리는 코드를 저장하고 수정할 수 있습니다. 리포지토리를 구성할 때 다음 옵션을 고려합니다.

Git 및 Team Foundation 버전 제어(TFVC)

Azure Repos는 팀이 선택할 수 있는 다음 버전 제어 시스템을 제공합니다.

  • Git 및 TFVC. 프로젝트에는 각 형식의 리포지토리가 있을 수 있습니다. 기본적으로 새 프로젝트에는 빈 Git 리포지토리가 있습니다. Git은 개발자 워크플로에서 많은 유연성을 제공하고 개발자 에코시스템의 거의 모든 관련 도구와 통합됩니다. 모든 프로젝트에서 Git 리포지토리를 사용할 수 있습니다. 프로젝트에 추가할 수 있는 Git 리포지토리의 양에는 제한이 없습니다.

TFVC는 사용할 수 있는 중앙 집중식 버전 제어 시스템입니다. Git과 달리 프로젝트에는 하나의 TFVC 리포지토리만 허용됩니다. 그러나 해당 리포지토리 내에서 폴더 및 분기는 원하는 경우 여러 제품 및 서비스에 대한 코드를 구성하는 데 사용됩니다. 프로젝트는 적절한 경우 TFVC와 Git를 모두 사용할 수 있습니다.

Monorepo 및 서비스당 하나의 리포지토리

모노레포에서 다양한 독립 서비스를 배포하는 것은 초기 모멘텀을 구축하는 것을 목표로 하는 소규모 팀에 효과적일 수 있습니다. 그러나 이 전략은 다음과 같은 몇 가지 요인으로 인해 팀이 성장함에 따라 문제가 될 수 있습니다.

  • 새 멤버에 필요한 지식은 시스템의 전반적인 복잡성에 따라 증가합니다.
  • 단일 리포지토리 내에서 코드를 공유하면 서비스 간에 의도하지 않은 결합이 발생할 수 있습니다.
  • 공유 코드의 변경은 다양한 서비스의 동작에 영향을 주므로 이러한 변경 내용을 추적하기가 어려울 수 있습니다.

대규모 팀의 경우 모노레포를 관리하려면 강력한 엔지니어링 분야와 강력한 도구가 필요합니다. 또는 공유 리소스에 대한 별도의 리포지토리와 함께 각 서비스에 대한 개별 리포지토리를 선택할 수 있습니다. 이 방법은 더 많은 초기 설정을 포함하지만 팀이 성장함에 따라 더 효과적으로 확장됩니다. 또한 특정 서비스 리포지토리에만 집중할 수 있는 새 멤버의 온보딩이 더 쉬워집니다.

소규모 팀으로 시작하는 경우 모노레포를 선택하는 것이 좋습니다. 팀이 확장되고 복잡성이 증가함에 따라 별도의 리포지토리로 전환할 수 있습니다.

프로젝트 내의 1개 및 여러 리포지토리

단일 프로젝트 내에서 여러 리포지토리를 설정하거나 프로젝트당 리포지토리를 설정해야 하나요? 다음 지침은 해당 리포지토리의 계획 및 관리 기능과 관련이 있습니다.

제품/서비스가 조정된 릴리스 일정에 따라 작업하는 경우 여러 리포지토리를 포함하는 하나의 프로젝트가 잘 작동합니다. 개발자가 여러 리포지토리를 자주 사용하는 경우 단일 프로젝트에 유지하여 프로세스가 공유되고 일관성을 유지할 수 있도록 합니다. 액세스 제어 및 사례 적용 및 최대 파일 크기와 같은 옵션이 프로젝트 수준에서 설정되므로 단일 프로젝트 내에서 리포지토리 액세스를 관리하는 것이 더 쉽습니다. 리포지토리가 단일 프로젝트에 있더라도 액세스 제어 및 설정을 개별적으로 관리할 수 있습니다.

여러 리포지토리에 저장된 제품이 독립적인 일정 또는 프로세스에서 작동하는 경우 여러 프로젝트로 분할할 수 있습니다. Git 리포지토리 이식성을 사용하면 프로젝트 간에 리포지토리를 쉽게 이동할 수 있으며 여전히 전체 충실도 커밋 기록을 유지할 수 있습니다. 끌어오기 요청 또는 빌드 기록과 같은 다른 기록은 쉽게 마이그레이션되지 않습니다.

다음 요소와 팁에 따라 하나의 리포지토리와 여러 리포지토리에 대한 결정을 기반으로 합니다.

  • 코드 종속성 및 아키텍처
  • 독립적으로 배포할 수 있는 각 제품 또는 서비스를 자체 리포지토리에 배치
  • 이러한 리포지토리에서 조정된 코드를 변경해야 하는 경우 코드베이스를 여러 리포지토리로 분리하지 마세요. 이러한 변경 내용을 조정하는 데 도움이 되는 도구는 없기 때문에
  • 코드베이스가 이미 모놀리식인 경우 하나의 리포지토리에 보관합니다. 모놀리식 리포지토리에 대한 자세한 내용은 Microsoft가 DevOps 문서를 사용하여 최신 소프트웨어를 개발하는 방법을 참조하세요.
  • 연결이 끊긴 서비스가 많은 경우 서비스당 하나의 리포지토리가 좋은 전략입니다.

팁

조직의 모든 사용자가 리포지토리를 만들 수 없도록 사용 권한을 관리하는 것이 좋습니다. 리포지토리가 너무 많은 경우 해당 리포지토리에 저장된 코드 또는 기타 콘텐츠를 누가 소유하는지 추적하기가 어렵습니다.

공유 repo 대 포크된 reops

신뢰할 수 있는 조직 내에서 공유 리포지토리를 사용하는 것이 좋습니다. 개발자는 분기를 사용하여 서로의 변경 내용을 격리합니다. 좋은 분기 및 릴리스 전략을 사용하면 단일 리포지토리를 확장하여 1,000명 이상의 개발자를 위한 동시 개발을 지원할 수 있습니다. 분기 및 릴리스 전략에 대한 자세한 내용은 Git 분기 전략 및 릴리스 흐름 채택: 분기 전략을 참조 하세요.

포크는 기본 리포지토리를 업데이트하기 위해 직접 액세스할 수 없어야 하는 공급업체 팀과 함께 작업할 때 유용할 수 있습니다. 포크는 오픈 소스 프로젝트와 같이 많은 개발자가 자주 기여하지 않는 시나리오에서도 유용할 수 있습니다. 포크를 사용하는 경우 포크된 리포지토리를 기본 리포지토리에서 격리하기 위해 별도의 프로젝트를 유지 관리할 수 있습니다. 관리 오버헤드가 추가될 수 있지만 기본 프로젝트 클리너를 유지합니다. 자세한 내용은 포크 문서를 참조 하세요.

다음 이미지는 "회사"가 조직, 프로젝트, 작업 항목, 팀 및 리포지토리를 구성하는 방법에 대한 샘플을 표시합니다.

회사의 조직 구조를 보여 주는 다이어그램

임시 및 공유 리소스 관리

다음 모범 사례를 사용하여 임시 및 공유 리소스를 효과적으로 관리하는 방법을 고려합니다.

  • 임시 환경: 임시 환경은 수명이 짧으며 테스트, 개발 또는 스테이징과 같은 작업에 사용됩니다. 이러한 환경을 효율적으로 관리하려면 다음을 수행합니다.
    • 별도의 리포지토리 및 파이프라인: 각 임시 환경 및 연결된 리소스(예: Azure Functions)에는 자체 리포지토리와 파이프라인이 있어야 합니다. 이러한 분리를 통해 환경과 해당 리소스를 동시에 배포하고 롤백할 수 있으므로 필요에 따라 더 쉽게 스핀업하고 삭제할 수 있습니다.
    • 예: Azure Functions, 스토리지 계정 및 기타 서비스와 같은 모든 필요한 리소스를 포함하여 개발 환경에 맞게 리포지토리 및 파이프라인을 만듭니다.
  • 공유 리소스: 공유 리소스는 일반적으로 수명이 길며 여러 환경에서 사용됩니다. 이러한 리소스는 스핀업 시간이 길고 비용이 높은 경우가 많습니다. 공유 리소스를 효과적으로 관리하려면 다음을 수행합니다.
    • 별도의 리포지토리 및 파이프라인: Azure SQL Database와 같은 공유 리소스에는 자체 리포지토리 및 파이프라인이 있어야 합니다. 이렇게 분리하면 임시 환경에서 이러한 공유 리소스를 사용할 수 있으므로 배포가 더 빠르고 비용 효율적입니다.
    • 예: 여러 임시 환경에서 사용할 수 있는 Azure SQL Database에 대한 리포지토리 및 파이프라인을 만듭니다.
  • 공유 인프라 리소스: VPC(가상 프라이빗 클라우드) 및 랜딩 존이라고도 하는 서브넷과 같은 공유 인프라 리소스에는 자체 리포지토리 및 파이프라인도 있어야 합니다. 이 방법을 사용하면 인프라가 일관되게 관리되고 다양한 환경에서 다시 사용할 수 있습니다.
    • 예: 다른 리포지토리 및 파이프라인에서 참조할 수 있는 VPC 및 서브넷 구성에 대한 리포지토리 및 파이프라인을 만듭니다.

조직 구조에 대한 자세한 정보

조직 관리자 계정 유형 선택

조직을 만들 때 로그인한 자격 증명은 조직에서 사용하는 ID 공급자를 정의합니다. Microsoft 계정 또는 Microsoft Entra 인스턴스를 사용하여 조직을 만듭니다. 해당 자격 증명을 사용하여 새 조직에 https://dev.azure.com/{YourOrganization}관리자로 로그인합니다.

Microsoft 계정 사용

Microsoft Entra ID를 사용하여 조직의 사용자를 인증할 필요가 없는 경우 Microsoft 계정을 사용합니다. 모든 사용자는 Microsoft 계정으로 조직에 로그인해야 합니다. 계정이 없는 경우 Microsoft 계정을 만듭니다.

암호를 입력하고 로그인합니다.

Microsoft Entra 인스턴스가 없는 경우 Azure Portal에서 무료로 만들거나 Microsoft 계정을 사용하여 조직을 만듭니다. 그런 다음, 조직을 Microsoft Entra ID에 연결할 수 있습니다.

Microsoft Entra 계정 사용

Azure 또는 Microsoft 365를 사용하는 경우 이미 Microsoft Entra 계정이 있을 수 있습니다. Microsoft Entra ID를 사용하여 사용자 권한을 관리하는 회사에서 작업하는 경우 Microsoft Entra 계정이 있을 수 있습니다.

Microsoft Entra 계정이 없는 경우 Microsoft Entra ID 에 등록하여 조직을 Microsoft Entra ID에 자동으로 연결합니다. 조직에 액세스하려면 모든 사용자가 해당 디렉터리의 구성원이어야 합니다. 다른 조직의 사용자를 추가하려면 Microsoft Entra B2B 협업을 사용합니다.

Azure DevOps는 Microsoft Entra ID를 통해 사용자를 인증하므로 해당 디렉터리의 구성원인 사용자만 조직에 액세스할 수 있습니다. 해당 디렉터리에서 사용자를 제거하면 더 이상 조직에 액세스할 수 없습니다. 특정 Microsoft Entra 관리자 만 디렉터리의 사용자를 관리하므로 관리자는 조직에 액세스하는 사용자를 제어합니다.

사용자 관리에 대한 자세한 내용은 사용자 관리를 참조 하세요.

사업부에 조직 매핑

회사 내의 각 사업부는 자체 Microsoft Entra 테넌트와 함께 Azure DevOps에서 자체 조직을 가져옵니다. 필요에 따라 팀 또는 진행 중인 작업에 따라 해당 개별 조직 내에서 프로젝트를 설정할 수 있습니다.

대규모 회사의 경우 다른 사용자 계정(Microsoft Entra 계정일 가능성이 높음)을 사용하여 여러 조직을 만들 수 있습니다. 어떤 그룹과 사용자가 전략과 작업을 공유하는지 고려하고 특정 조직으로 그룹화합니다.

예를 들어 가상의 Fabrikam 회사는 다음 세 개의 조직을 만들었습니다.

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

각 조직에는 다음과 같은 별도의 URL이 있습니다.

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

조직은 동일한 회사를 위한 것이지만 대부분 서로 격리되어 있습니다. 당신은 이런 식으로 아무것도 분리 할 필요가 없습니다. 비즈니스에 적합한 경우에만 경계를 만듭니다.

팁

다른 조직을 결합하는 것보다 기존 조직을 프로젝트로 더 쉽게 분할할 수 있습니다.