Microsoft Power Platform을 사용하는 ALM 기본 사항

  • 아티클

이 문서에서는 ALM(애플리케이션 수명 주기 관리)을 구현하는 데 필요한 구성 요소, 도구, 프로세스에 대해 설명합니다.

환경

환경은 조직의 비즈니스 데이터, 앱, 비즈니스 프로세스를 저장, 관리, 공유하는 공간입니다. 또한 역할, 보안 요구 사항, 대상 그룹이 달라질 수 있는 앱을 분리하기 위한 컨테이너 역할을 합니다. 각 환경에는 하나의 Microsoft Dataverse 데이터베이스만 허용됩니다. 추가 정보: 환경 개요

중요

환경을 생성할 때 Dynamics 365 Sales 또는 Dynamics 365 Marketing과 같은 Dynamics 365 앱을 설치하도록 선택할 수 있습니다. 이 앱을 나중에 제거하거나 나중에 설치할 수 없기 때문에 이러한 앱이 필요한지 여부를 결정하는 것이 중요합니다. 이러한 앱을 구축하지 않고 향후 필요하지 않을 경우 환경에 설치하지 않는 것이 좋습니다. 이렇게 하면 여러 환경에 솔루션을 배포할 때 종속성 복잡성을 피할 수 있습니다.

ALM에 사용되는 환경 유형

Power Platform 관리 센터를 사용하면 다음과 같은 Power Platform 환경 유형을 만들 수 있습니다.

  • 샌드박스 샌드박스 환경은 Dataverse의 비프로덕션 환경입니다. 프로덕션에서 격리된 샌드박스 환경은 안전하게 개발하고 애플리케이션 변경 사항을 테스트할 수 있는 위험이 적은 장소입니다. 샌드박스 환경에는 초기화, 삭제, 복사 작업 등 프로덕션 환경에 부정적일 수 있는 기능이 포함됩니다. 추가 정보: 샌드박스 환경 관리

  • 생산 앱 및 기타 소프트웨어가 의도된 용도로 동작하는 환경입니다.

  • 개발자(공식적으로 커뮤니티라고 함). Power Apps 개발자 플랜은 개별 사용을 위해 Power Apps 프리미엄 기능, Dataverse 및 Power Automate에 대한 액세스를 제공합니다. 이 플랜은 주로 Power Apps, Power Automate 및 Microsoft Dataverse를 사용하여 빌드하고 테스트하거나 학습 목적으로 사용됩니다. 개발자 환경은 단일 사용자 환경이므로 프로덕션 앱을 실행하거나 공유하는 데 사용할 수 없습니다.

  • 기본값 단일 기본 환경은 각 테넌트에 대해 자동으로 생성되어 해당 테넌트의 모든 사용자에게 공유됩니다. 테넌트는 하나 이상의 Microsoft 구독 및 연관 서비스를 보유한 고객을 식별합니다. 새 사용자가 Power Apps에 등록할 때마다 자동으로 기본 환경의 제작자 역할에 추가합니다. 기본 환경은 Microsoft Entra 테넌트의 기본 지역과 가장 가까운 지역에 생성되며 이름은 "{Microsoft Entra tenant name} (default)"입니다.

개발, 테스트, 프로덕션과 같은 특정 목적에 대한 올바른 환경을 만들고 사용하세요.

환경에 대한 자세한 내용은 환경 개요를 참조하세요.

누가 액세스해야 합니까?

Microsoft Dataverse 내의 리소스 및 데이터의 보안을 정의하고 관리합니다. Microsoft Power Platform은 작업을 수행하기 위한 환경 수준의 관리자 역할을 제공합니다. Dataverse는 Dataverse 내에서 앱 제작자 및 사용자가 보유한 앱, 앱 구성 요소, 리소스에 대한 액세스 수준을 정의하는 보안 역할을 포함합니다.

환경 용도 액세스 권한이 있는 역할 주석
개발 앱 제작자와 개발자. 앱 사용자는 액세스할 수 없습니다. 개발자가 리소스를 제작하기 위해서는 최소 환경 결정자 보안 역할이 필요합니다.
테스트 관리자 및 테스트하는 사람. 앱 제작자, 개발자, 및 프로덕션 앱 사용자는 액세스할 수 없습니다. 테스트 사용자는 테스트를 수행할 수 있는 충분한 권한이 필요합니다.
생산 관리자 및 앱 사용자. 사용자는 사용하는 앱에 대한 작업을 수행할 수 있는 충분한 액세스 권한이 필요합니다. 앱 제작자와 개발자는 액세스 권한이 없거나 사용자 수준의 권한만이 제공됩니다.
기본 기본적으로 테넌트의 모든 사용자는 Dataverse의 데이터베이스가 있는 기본 환경에서 앱을 만들고 편집할 수 있습니다. 특정 목적을 위한 환경을 만들고 필요한 사람에게만 적절한 역할과 권한을 부여하는 것이 좋습니다.

추가 정보:

솔루션

솔루션을 활용해 환경 간 앱 및 구성 요소를 전송하거나 기존 앱에 사용자 지정 집합을 적용합니다.

솔루션에는 다음과 같은 기능이 있습니다.

  • 솔루션에는 메타데이터 및 구성 데이터가 있는 특정 엔터티가 포함됩니다. 솔루션은 비즈니스 데이터를 포함하지 않습니다.

  • 솔루션은 모델 중심 앱, 캔버스 앱, 사이트 맵, 흐름, 엔터티, 양식, 사용자 지정 커넥터, 웹 리소스, 옵션 집합, 차트 및 필드와 같은 다양한 Microsoft Power Platform 구성 요소를 포함할 수 있습니다. 모든 엔터티가 솔루션에 포함되는 것은 아닙니다. 예를 들어 애플리케이션 사용자, 사용자 정의 API 및 조직 설정 시스템 테이블은 솔루션에 추가할 수 없습니다.

  • 이들 엔터티는 다른 환경으로 내보내거나 가져오기 위한 단위로 패키지되거나 자산의 소스 코드로서 소스 컨트롤에 분석되고 체크인됩니다. 또한 솔루션은 기존 솔루션에 변경 사항을 적용하는 데에도 사용됩니다.

  • 관리형 솔루션은 해당 솔루션의 개발 환경이 아닌 모든 환경에 배포하는 데 사용됩니다. 여기에는 테스트, UAT(사용자 수용 테스트), SIT(시스템 통합 테스트) 및 프로덕션 환경이 포함됩니다. 관리형 솔루션은 업그레이드, 패치, 삭제 등 환경 내 다른 관리형 솔루션으로부터 독립적으로 서비스할 수 있습니다. ALM 모범 사례로서 관리형 솔루션은 빌드 서버에서 생성하고 빌드 아티팩트로 간주해야 합니다.

  • 관리형 솔루션의 업데이트는 이전 버전의 관리형 솔루션에 배포됩니다. 이때 추가 솔루션 레이어를 생성하지 않습니다. 업데이트를 사용해 구성 요소를 삭제할 수 없습니다.

  • 패치에는 상위 관리형 솔루션에 대한 변경 사항만 포함됩니다. 패치는 핫픽스와 유사한 소규모 업데이트 시에만 사용해야 하며, 삭제도 가능해야 합니다. 패치를 가져오면 상위 솔루션 위에 계층화됩니다. 패치를 사용해 구성 요소를 삭제할 수 없습니다.

  • 솔루션을 업그레이드하면 기본 레이어 및 기존 패치 위에 즉시 새 솔루션 레이어가 설치됩니다.

    • 솔루션 업그레이드를 적용하면 모든 기존 패치 및 기본 레이어를 삭제합니다.

    • 솔루션 업그레이드는 존재하지만 더 이상 업그레이드된 버전에 포함되지 않는 구성 요소를 삭제합니다.

자세한 내용은 솔루션 개념을 참조하십시오.

소스 컨트롤

버전 제어라고도 하는 소스 컨트롤은 소프트웨어 개발 자산을 유지 관리하고 안전하게 보관하며 해당 자산의 변경 사항을 추적하는 시스템입니다. 변경 내용 추적은 여러 앱 제작자와 개발자가 동일한 파일 집합을 작업할 때 특히 중요합니다. 또한 소스 컨트롤 시스템은 변경 사항을 롤백하거나 삭제된 파일을 복원하는 기능을 제공합니다.

소스 제어 시스템은 소스 제어 시스템에서 유지 관리되는 자산이 "단일 소스", 즉 솔루션에 대한 단일 액세스 및 수정 지점이기 때문에 조직이 건강한 ALM을 달성하는 데 도움이 됩니다.

분기 및 병합 전략

거의 모든 소스 컨트롤 시스템은 일정 형태의 분기 및 병합 지원을 지원합니다. 분기는 기본 라인을 변경하지 않고도 기본 개발 라인에서 벗어나 계속 작업을 수행함을 의미합니다. 병합 프로세스는 개발 분기에서 기본 라인 분기를 병합하는 등 분기를 다른 분기로 결합합니다. 몇 가지 일반적인 분기 전략으로 트렁크 기반 분기, 릴리스 분기 및 기능 분기가 있습니다. 자세한 정보는 Git 분기 전략 채택을 참조하십시오.

솔루션을 사용한 소스 컨트롤 프로세스

소스 컨트롤 시스템에서 솔루션으로 작업할 때 두 가지 경로를 사용할 수 있습니다.

  • 비관리형 솔루션을 내보낸 뒤 소스 컨트롤 시스템에서 압축을 풉니다. 빌드 프로세스에서 비관리형 상태의 압축된 솔루션을 임시 빌드 환경(샌드박스 환경)으로 가져옵니다. 그런 다음 솔루션을 관리형으로 내보내고 소스 컨트롤 시스템에서 빌드 아티팩트로 저장합니다.
  • 솔루션을 비관리형으로 및 관리형으로 내보내고 소스 컨트롤 시스템에 모두 배치합니다. 이 방법에는 빌드 환경이 필요하지 않지만 모든 구성 요소의 두 복사본(비관리형 솔루션의 모든 비관리형 구성 요소의 복사본 한 개, 관리형 솔루션의 모든 관리형 구성 요소의 복사본 한 개)을 유지해야 합니다.

솔루션을 사용한 소스 컨트롤.

자세한 정보는 도구 빌드 작업을 참조하십시오.

자동화

자동화는 ALM의 생산성과 신뢰성, 품질 및 효율성을 향상시키는 애플리케이션 수명 주기의 핵심입니다. 자동화 도구 및 작업은 샌드박스 환경을 만들고 초기화하는 것은 물론 솔루션의 유효성을 검사하고 내보내고, 압축하거나 압축을 푸는 데 사용됩니다.

자세한 내용은 Microsoft Power Platform Build Tools는 무엇입니까?를 참조하십시오.

공유 소스 컨트롤을 사용한 팀 개발

프로젝트를 빌드할 때 개발팀과 협력하는 방법을 고려하는 것이 중요합니다. 사일로를 분석하고 의견 및 대화를 장려하면 팀이 더 나은 소프트웨어를 개발할 수 있습니다. Git, GitHub 및 Azure DevOps에서 제공되는 것과 같은 일부 도구 및 워크플로는 커뮤니케이션 및 소프트웨어 품질을 개선하려는 명시적인 목적을 위해 설계되었습니다. 솔루션 시스템에서 구성 작업을 수행하면 팀 개발에 문제가 발생할 수 있습니다. 소스 컨트롤 시스템의 병합 발생 방법에는 제한이 있으므로 조직은 발생 가능한 병합 충돌을 피하기 위해 여러 개발자의 변경 사항을 조율해야 합니다. 여러 사람이 양식, 흐름 및 캔버스 앱과 같은 복잡한 구성 요소를 동시에 변경하는 상황을 피하는 것이 좋습니다.

자세한 정보는 5번 시나리오: 지원팀 개발을 참조하십시오.

연속 통합 및 배포

모든 소스 컨트롤 시스템을 사용하고 파이프라인을 구축하여 연속 통합 및 배포(CI/CD)를 시작할 수 있습니다. 그러나 이 가이드는 GitHub 및 Azure DevOps를 집중적으로 다룹니다. GitHub는 수백만 명의 개발자가 사용하는 개발 플랫폼입니다. Azure DevOps는 지원팀이 작업을 계획하고, 코드 개발을 위해 협업하며, 애플리케이션을 구축 및 배포할 수 있는 개발자 서비스를 제공합니다.

시작하려면 다음이 필요합니다.

자세한 내용은 첫 파이프라인 만들기를 참조하십시오.

라이선싱

Power Apps 및 Power Automate를 사용해 앱 및 흐름을 만들거나 편집하려면 사용자는 Power Apps나 Power Automate 또는 적절한 Dynamics 365 애플리케이션 라이선스의 사용자별 라이선스를 보유해야 합니다. 자세한 내용은 Microsoft Power Platform용 라이선스 개요를 참조하십시오. 또한 라이선스 요구 사항에 대해서는 Microsoft 계정 담당자에게 문의하십시오.

ALM 고려 사항

Microsoft Power Platform에서 앱을 구축할 때 필수 요소로 ALM을 고려할 경우, 앱의 속도와 안정성 및 사용자 경험을 크게 향상시킬 수 있습니다. 또한 코드를 작성하는 기존 개발자 및 시민 개발자 모두가 공동으로 빌드 중인 애플리케이션에 기여할 수 있도록 합니다.

애플리케이션 개발 초기에 고려해야 할 여러 항목을 설명하는 다음 기사를 참조하십시오.