다음을 통해 공유

Azure 랜딩 존에 대한 테스트 기반 개발

  • 아티클

TDD(테스트 기반 개발)는 코드 기반 솔루션의 새로운 기능 품질과 향상된 기능을 향상시키는 소프트웨어 개발 및 DevOps 프로세스입니다. TDD는 실제 코드를 개발하기 전에 단위 테스트 사례를 만들고 테스트 사례에 대해 코드를 테스트합니다. 이 방법은 먼저 코드를 개발하고 나중에 테스트 사례를 만드는 것과 반대됩니다.

랜딩 존 코드를 통해 미리 프로비전되는 워크로드를 호스팅하는 환경입니다. 랜딩 존에는 정의된 클라우드 서비스 및 모범 사례 집합을 사용하는 기본 기능이 포함됩니다. 이 문서에서는 TDD를 사용하여 품질, 보안, 운영 및 거버넌스 요구 사항을 충족하는 동안 성공적인 랜딩 존을 배포하는 방법을 설명합니다.

클라우드 인프라는 코드 실행의 출력입니다. 잘 구조화되고 테스트되고 확인된 코드는 실행 가능한 랜딩 존을 생성합니다. 클라우드 기반 인프라 및 기본 소스 코드는 이 방법을 사용하여 랜딩 존이 고품질이고 핵심 요구 사항을 충족하도록 할 수 있습니다.

초기 개발 중에 간단한 기능 요청을 충족하려면 이 방법을 사용합니다. 클라우드 채택 수명 주기의 뒷부분에서 이 프로세스를 사용하여 보안, 운영, 거버넌스 또는 규정 준수 요구 사항을 충족할 수 있습니다. 이 프로세스는 병렬 개발 작업에서 랜딩 존을 개발하고 리팩터링하는 데 특히 유용합니다.

테스트 기반 개발 주기

다음 다이어그램은 Azure 랜딩 존에 대한 테스트 기반 개발 주기를 보여 줍니다.

Azure 랜딩 존에 대한 테스트 기반 개발 프로세스의 다이어그램입니다.

  1. 테스트를 만듭니다. 기능에 대한 수락 조건이 충족되었는지 확인하는 테스트를 정의합니다. 특히 엔터프라이즈 규모 배포의 경우 수동 테스트 작업의 양을 줄이기 위해 개발 시 테스트를 자동화합니다.

  2. 랜딩 존을 테스트합니다. 새 테스트 및 기존 테스트를 실행합니다. 필요한 기능이 클라우드 공급자의 제품에 포함되지 않고 이전 개발 작업에서 제공되지 않은 경우 테스트가 실패해야 합니다. 기존 테스트를 실행하면 새 기능 또는 테스트가 기존 랜딩 존 기능의 안정성을 저하시키지 않는지 확인하는 데 도움이 됩니다.

  3. 랜딩 존을 확장하고 리팩터링합니다. 소스 코드를 추가하거나 수정하여 요청된 값 추가 기능을 수행하고 코드 베이스의 일반 품질을 향상시킵니다.

    TDD 조건을 충족하기 위해 클라우드 플랫폼 팀은 요청된 기능을 충족하는 코드만 추가합니다. 그러나 코드 품질 및 유지 관리는 공유 작업입니다. 클라우드 플랫폼 팀은 새로운 기능 요청을 처리할 때 중복을 제거하고 코드를 명확히 하여 코드를 개선해야 합니다. 새 코드 만들기와 소스 코드 리팩터링 간에 테스트를 실행하는 것이 좋습니다.

  4. 랜딩 존을 배포합니다. 소스 코드가 기능 요청을 충족하면 제어된 테스트 또는 샌드박스 환경에서 클라우드 공급자에게 수정된 랜딩 존을 배포합니다.

  5. 랜딩 존을 테스트합니다. 랜딩 존을 다시 테스트하여 새 코드가 요청된 기능에 대한 수락 조건을 충족하는지 확인합니다. 모든 테스트가 통과되면 기능이 완료된 것으로 간주되고 승인 기준이 충족되는 것으로 간주됩니다.

TDD 주기는 완료된전체 정의를 충족할 때까지 이전의 기본 단계를 반복합니다. 모든 부가 가치 기능 및 수용 조건이 관련 테스트를 통과하면 랜딩 존은 클라우드 채택 계획의 다음 물결을 지원할 준비가 됩니다.

TDD를 효과적으로 만드는 사이클을 종종 레드/그린 테스트라고 부른다. 이 접근 방식에서 클라우드 플랫폼 팀은 완료 정의와 정의된 수용 기준에 따라 실패한 테스트, 즉 빨간색 테스트로 시작합니다. 각 기능 또는 수용 기준에 대해 클라우드 플랫폼 팀은 테스트가 통과하거나 녹색 테스트를 수행할 때까지 개발 작업을 완료합니다.

TDD의 목표는 테스트 제품군을 만드는 것이 아니라 더 나은 디자인을 해결하는 것입니다. 테스트는 프로세스를 완료하는 데 유용한 아티팩트입니다.

완료 정의

성공은 랜딩 존 개발 또는 리팩터링 중에 클라우드 플랫폼 팀에게 실행 가능한 정보를 거의 제공하지 않는 주관적인 기준이 될 수 있습니다. 명확성이 부족하면 클라우드 환경에서 기대와 취약성을 놓칠 수 있습니다. 클라우드 플랫폼 팀이 랜딩 존을 리팩터링하거나 확장하기 전에 각 랜딩 존에 대한 DoD(완료)의 정의에 대한 명확성을 추구해야 합니다.

DoD는 클라우드 플랫폼 팀과 영향을 받는 다른 팀 간의 간단한 계약으로, 랜딩 존 개발 노력에 포함할 예상 부가가치 기능을 정의합니다. DoD는 종종 단기 클라우드 채택 계획과 맞물리는 검사 목록입니다.

팀이 더 많은 워크로드 및 클라우드 기능을 채택함에 따라 DoD와 수용 기준은 더욱 복잡해집니다. 완성도 높은 프로세스에서 예상된 기능은 각각 보다 명확하게 하기 위한 자체 수용 기준을 가지고 있습니다. 부가 가치 기능이 모두 수용 기준을 충족하는 경우 랜딩 존은 현재 채택 웨이브 또는 릴리스의 성공을 가능하게 충분히 구성됩니다.

간단한 DoD 예제

초기 마이그레이션 작업의 경우 미 국방부(DoD)는 지나치게 단순할 수 있습니다. 다음 예제는 간단한 DoD입니다.

초기 랜딩 존은 초기 학습을 위해 10개의 워크로드를 호스트합니다. 이러한 워크로드는 비즈니스에 중요하지 않으며 중요한 데이터에 액세스할 수 없습니다. 향후 이러한 워크로드는 프로덕션으로 릴리스될 수 있지만 중요도와 민감도는 변경되지 않을 것으로 예상됩니다.

이러한 워크로드를 지원하려면 클라우드 채택 팀이 다음 기준을 충족해야 합니다.

  • 제안된 네트워크 디자인에 맞게 네트워크 세분화 이 환경은 공용 인터넷에 액세스할 수 있는 경계 네트워크여야 합니다.
  • 컴퓨팅, 스토리지 및 네트워킹 리소스에 액세스하여 디지털 자산 검색에 맞게 조정된 워크로드를 호스트합니다.
  • 사용 편의성을 위해 스키마 이름 지정 및 태그 지정
  • 채택하는 동안 클라우드 채택 팀이 서비스 구성을 변경하기 위한 임시 액세스입니다.
  • 프로덕션 릴리스 전에 회사 ID 공급자와 통합하여 운영 관리에 대한 지속적인 ID 및 액세스를 제어합니다. 이때 클라우드 채택 팀의 액세스 권한을 취소해야 합니다.

마지막 지점은 기능 또는 수락 기준이 아니라 더 많은 확장이 필요하고 다른 팀과 조기에 탐색해야 한다는 지표입니다.

더 복잡한 DoD 예제

클라우드 채택 프레임워크 내의 지배 방법론은 거버넌스 팀의 자연스러운 성숙 과정을 안내합니다. 그 여정에 내재된 것은 정책 설명의 형태로 된 DoD 및 수용 기준의 몇 가지 예입니다.

  • 초기 정책 성명서. 초기 단계 채택 요구 사항을 제어하는 회사 정책을 기반으로 하는 초기 DoD의 예입니다.

  • ID 관리 확장을 위한 증분 개선 사항및 . 랜딩 존에 대한 ID 관리를 확장하기 위한 요구 사항을 충족하기 위해 DoD를 관리하는 회사 정책의 예입니다.

  • 보안 요구 사항을 확장하기 위한 증분 개선 사항. 참조 클라우드 채택 계획에 부합하는 보안 요구 사항을 충족하기 위해 DoD를 관리하는 회사 정책의 예입니다.

  • 단계적인 개선으로 운영 관리를 확장합니다. 기본 운영 관리 요구 사항을 충족하기 위해 DoD를 관리하는 회사 정책의 예입니다.

  • 비용 관리확장을 위한 증분 개선 사항. 비용 관리 요구 사항을 충족하기 위해 DoD를 관리하는 회사 정책의 예입니다.

앞의 예제는 랜딩 존에 대한 DoD를 개발하는 데 도움이 되는 기본 샘플입니다.

랜딩 존 TDD를 지원하는 Azure 도구 및 기능

다음 다이어그램은 Azure에서 사용 가능한 테스트 기반 개발 도구를 보여줍니다.

Azure에서 사용 가능한 테스트 기반 개발 도구를 보여 주는 다이어그램

랜딩 존을 만들기 위해 이러한 Azure 도구 및 기능을 TDD에 쉽게 통합할 수 있습니다. 이 도구는 TDD 주기에 맞게 랜딩 존을 더 쉽게 개발, 테스트 및 배포할 수 있도록 특정 용도로 사용됩니다.

  • Azure Resource Manager 빌드 및 배포 프로세스를 위한 일관된 플랫폼을 제공합니다. Resource Manager 플랫폼은 소스 코드 정의에 따라 랜딩 존을 배포할 수 있습니다.

  • ARM(Azure Resource Manager) 템플릿은 Azure에 배포된 환경에 대한 주 소스 코드를 제공합니다. Terraform과 같은 일부 타사 도구는 Azure Resource Manager에 제출할 자체 ARM 템플릿을 제공합니다.

  • Azure 퀵스타트 템플릿은 랜딩 존 및 워크로드 배포를 가속화하는 데 도움이 되는 소스 코드 템플릿을 제공합니다.

  • Azure Policy DoD에서 승인 조건을 테스트하기 위한 기본 메커니즘을 제공합니다. 또한 Azure Policy는 배포가 거버넌스 정책에서 벗어날 때 자동화된 검색, 보호 및 해결 방법을 제공할 수 있습니다.

    TDD 주기에서 단일 승인 조건을 테스트하는 정책 정의를 만들 수 있습니다. Azure Policy에는 DoD 내에서 개별 승인 조건을 충족할 수 있는 기본 제공 정책 정의 포함되어 있습니다. 이 방법은 랜딩 존을 수정하기 전에 빨간색 테스트 메커니즘을 제공합니다.

    Azure Policy에는 랜딩 존에 대한 전체 DoD를 테스트하고 적용하는 데 사용할 수 있는 기본 제공 정책 이니셔티브가 포함되어 있습니다. 전체 구독에 할당된 정책 이니셔티브에 모든 승인 조건을 추가할 수 있습니다. 랜딩 존이 DoD를 충족하면 Azure Policy는 테스트 조건을 적용하여 이후 릴리스에서 테스트가 실패하게 만드는 코드 변경을 방지할 수 있습니다.

    TDD 접근 방식의 일부로 코드 워크플로로 Azure Policy를 디자인하고 검토합니다.

  • Azure Resource Graph 랜딩 존에 배포된 자산에 대한 정보를 기반으로 데이터 기반 테스트를 만들기 위한 쿼리 언어를 제공합니다. 채택 계획의 뒷부분에서 이 도구는 워크로드 자산과 기본 클라우드 환경 간의 상호 작용을 기반으로 복잡한 테스트를 정의할 수도 있습니다.

    Resource Graph에는 고급 쿼리 샘플포함되어 있으며, 고급 테스트 시나리오를 위해 랜딩 존 내에서 워크로드를 배포하는 방법을 이해하는 데 사용할 수 있습니다.

선호하는 접근 방식에 따라 다음 도구를 사용할 수도 있습니다.

다음 단계