조직 구조 계획

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

비즈니스 구조를 Azure DevOps에서 만드는 조직, 프로젝트 및 팀 수에 대한 가이드로 사용합니다. 이 포괄적인 계획 가이드는 개발 워크플로를 비즈니스 목표에 맞게 조정하는 최적의 조직 구조를 설계하는 데 도움이 됩니다.

전략적 계획 프레임워크

기본 구조 결정

Azure DevOps 구조를 안내하기 위해 다음과 같은 기본적인 질문을 해결합니다.

조직 수준:

• 얼마나 많은 조직이 필요한가요? - 보안, 규정 준수 및 사업부 분리 고려
• 조직을 사업부에 매핑하는 방법 - 엔터프라이즈 구조 및 거버넌스 요구 사항에 맞게 조정

프로젝트 수준:

• 필요한 프로젝트는 몇 개입니까? - 보안 및 자율성과의 협업 균형
• 프로젝트 매핑 전략 - 프로젝트를 비즈니스 기능 및 팀 구조에 연결

팀 및 리포지토리 수준:

• 팀 구조 디자인 - 민첩한 배달 및 제품 소유권 최적화
• 리포지토리 조직 - 개발 및 배포 워크플로 지원

지원 고려 사항

• 액세스 관리: 정보 및 리소스에 액세스해야 하는 사용자 정의
• 보고 요구 사항: 팀 간 가시성 및 포트폴리오 관리 계획
• 프로세스 표준화: 일관된 사례를 촉진하면서 팀의 유연성을 허용합니다.
• 문화적 맞춤: 민첩한 사고방식과 공동 작업 문화 조성

Azure DevOps 조직 이해

Azure DevOps의 조직은 청구, 보안 및 관리 경계를 제공하는 프로젝트의 최상위 컨테이너 역할을 합니다. 조직에서 다음을 수행할 수 있습니다.

• 관련 프로젝트 및 팀에서 청구 및 라이선스 중앙 집중화
• 고유한 액세스 제어 및 정책을 사용하여 보안 경계 설정
• 다양한 사업부 또는 규정 준수 요구 사항에 대한 관리 격리 제공
• 통합 인증을 위해 Microsoft Entra ID와 같은 ID 공급자에 연결

조직 혜택 및 무료 계층

각 조직에는 최대 5명의 사용자를 위한 무료 계층 서비스가 포함됩니다.

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

일반적인 조직 패턴:

• 단일 조직: 대부분의 회사는 통합 협업을 위해 한 조직의 혜택을 누릴 수 있습니다.
• 사업부 조직: 별도의 규정 준수 또는 보안 요구 사항을 위한 별도의 조직
• 지리적 조직: 데이터 보존 또는 지역 거버넌스를 위한 지역 분리

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

한 조직에서 시작하여 분리를 요구하는 특정 비즈니스 요구 사항이 있는 경우에만 확장합니다.

여러 조직에 대한 의사 결정 기준

필요한 경우 더 많은 조직을 만듭니다.

보안 및 규정 준수 분리:

• 다양한 규정 요구 사항(SOX, HIPAA, PCI-DSS)
• 고유한 고객 데이터 격리 요구 사항
• 별도의 감사 내역 및 규정 준수 보고

비즈니스 구조 요구 사항:

• 별도의 IT 거버넌스가 있는 독립 사업부
• 다양한 청구 및 비용 센터 요구 사항
• 별도의 ID 공급자 연결(다른 Microsoft Entra 테넌트)

관리 경계:

• 겹치지 않는 다른 관리자 그룹
• 별도의 조직 정책 및 컨트롤
• 독립 서비스 수준 계약

평가 체계

팀이란?

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

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

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

프로젝트 이해

프로젝트는 다음과 같은 통합 서비스를 포함하는 개발 작업에 대한 컨테이너를 제공합니다.

• Azure Boards: 백로그, 스프린트 및 작업 항목 추적을 사용하여 Agile 계획
• Azure Pipelines: 지속적인 통합 및 배포 자동화
• Azure Repos: 소스 코드 관리를 위한 Git 또는 TFVC 리포지토리
• Azure 테스트 계획: 수동 및 자동화된 테스트 통합
• 공유 리소스: Wiki, 대시보드 및 프로젝트 수준 설정

다음 예제에서 Contoso Manufacturing은 4개의 프로젝트를 사용하여 다른 제품 라인을 구성합니다.

프로젝트 이점 및 고려 사항

프로젝트 활성화:

• 팀 간 공유 반복 일정 및 분류
• 일관된 프로세스 템플릿 및 작업 항목 유형
• 통합 보고 및 포트폴리오 관리
• 간소화된 사용자 관리 및 액세스 제어

프로젝트는 다음을 위한 경계를 제공합니다.

• 보안 및 액세스 권한
• 프로세스 사용자 지정 및 작업 추적
• 관리 정책 및 거버넌스
• 리소스 할당 및 청구 추적

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

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

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

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

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

프로젝트 의사 결정 프레임워크

공동 작업 요구 사항에 따라 적절한 프로젝트 구조를 선택합니다.

단일 프로젝트 접근 방식:

• 최적 대상: 긴밀한 협업을 갖춘 소규모 조직 또는 팀
• 이점: 최대 가시성, 공유 리소스, 통합 보고
• 고려할 때: 팀들이 유사한 출시 주기를 가진 관련 제품에서 작업하는 경우

여러 프로젝트 접근 방식:

• 최적 대상: 고유한 요구 사항이 있는 독립 팀
• 이점: 보안 경계 개선, 사용자 지정 가능한 프로세스, 팀 자율성
• 고려할 시기: 다른 규정 준수 필요 사항 또는 개별 사업 부서

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

다음을 위해 여러 프로젝트를 고려합니다.

• 특정 정보에 대한 액세스 제한 또는 관리
• 여러 사업부에 대한 사용자 지정 작업 추적 프로세스 지원
• 독립적인 관리 정책을 사용하여 별도의 사업부 지원
• 프로덕션 출시 전에 사용자 지정 또는 확장 테스트

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

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

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

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

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

리포지토리 전략 및 버전 제어

팀 크기, 제품 아키텍처 및 배포 요구 사항에 따라 리포지토리 전략을 구성합니다.

버전 제어 시스템 선택

Git 및 TFVC(Team Foundation 버전 제어) 중에서 선택합니다.

Git 리포지토리:

• 최신 개발 워크플로에 권장되는 접근 방식
• 프로젝트당 무제한 리포지토리
• 분산 버전 관리와 유연한 브랜칭
• 대부분의 개발 도구 및 CI/CD 시스템과 통합

TFVC(Team Foundation 버전 제어):

• 중앙 집중식 버전 제어 시스템
• 폴더 기반 조직을 사용하는 프로젝트당 단일 리포지토리
• 중앙 집중식 워크플로를 선호하는 팀에 적합합니다.

리포지토리 조직 패턴

Monorepo 전략:

• 최적 대상: 관련 서비스를 사용하여 모멘텀을 구축하는 소규모 팀
• 이점: 간소화된 공유 및 조정된 변경
• 과제: 팀 성장에 따라 지식 복잡성이 증가합니다. 의도하지 않은 서비스 결합; 어려운 변경 내용 추적

별도의 리포지토리 전략:

• 최적 대상: 독립적인 서비스 배포를 사용하는 대규모 팀
• 이점: 서비스 경계 지우기, 더 쉬운 온보딩, 독립적인 릴리스 주기
• 고려 사항: 더 많은 초기 설정이 필요하지만 팀 성장에 따라 효과적으로 확장

리포지토리 및 프로젝트 맞춤 전략

여러 리포지토리가 있는 단일 프로젝트:

• 최적 대상: 조정된 릴리스 일정이 있는 제품/서비스
• 이점: 공유 프로세스, 일관된 액세스 제어, 간소화된 관리
• 사용 시기: 개발자는 여러 리포지토리에서 자주 작업하며 일관된 도구가 필요합니다.

전용 리포지토리가 있는 여러 프로젝트:

• 적합 대상: 독립적인 일정 또는 고유한 요구 사항이 있는 제품
• 이점: 독립적인 사용자 지정, 별도의 거버넌스, 명확한 경계

리포지토리 조직에 대한 의사 결정 요소:

• 코드 종속성: 독립적으로 배포 가능한 제품/서비스를 별도의 리포지토리에 배치
• 조정 요구 사항: 조정된 변경이 예상되는 경우 관련 코드베이스를 함께 유지
• 아키텍처: 단일 리포지토리에 기존 모놀리스를 유지 관리하고, 비연결 서비스를 분리합니다.
• 팀 액세스: 리포지토리 만들기를 제어하는 적절한 권한 관리 구현

공유 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

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

관련 콘텐츠

• 조직 만들기
• 프로젝트 만들기
• Microsoft Entra ID에 조직 연결
• 청구 설정
• 사용자 기본 설정 구성