Share via

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

  • 아티클

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

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

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

이 접근 방식을 사용하여 초기 개발 중에 단순한 기능 요청을 충족할 수 있습니다. 클라우드 채택 수명 주기 후반에는 이 프로세스를 사용하여 보안, 운영, 거버넌스 또는 규정 준수 요구 사항을 충족할 수 있습니다. 이 프로세스는 병렬 개발 활동에서 랜딩 존을 개발 및 리팩터링하는 데 특히 유용합니다.

테스트 기반 개발 주기

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

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

  1. 테스트를 만듭니다. 기능 수용 기준이 충족되었는지 유효성을 검사하는 테스트를 정의합니다. 개발 시 테스트를 자동화하여 수동 테스트 활동량(특히 엔터프라이즈 규모 배포의 경우)을 줄입니다.

  2. 랜딩 존을 테스트합니다. 새 테스트와 기존 테스트를 실행합니다. 필요한 기능이 클라우드 공급자의 제품에 포함되지 않고 이전 개발 활동에서 제공되지 않은 경우, 테스트는 실패해야 합니다. 기존 테스트를 실행하면 새 기능 또는 테스트가 기존 랜딩 존 기능의 안정성을 감소시키지 않는지 유효성을 검사하는 데 도움이 됩니다.

  3. 랜딩 존을 확장하고 리팩터링합니다. 요청된 부가가치 기능을 이행하고 코드 기반의 일반적인 품질을 개선하려면 소스 코드를 추가하거나 수정합니다.

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

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

  5. 랜딩 존을 테스트합니다. 랜딩 존을 다시 테스트하여 새 코드가 요청된 기능의 수용 기준을 충족하는지 유효성을 검사합니다. 모든 테스트를 통과하면 기능이 완전한 것으로 간주되고 수용 기준이 충족된 것으로 여겨집니다.

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

TDD를 효과적으로 만드는 주기를 흔히 레드/그린 테스트라고 합니다. 이 접근 방식에서 클라우드 플랫폼 팀은 완료 및 정의된 수용 기준의 정의를 기반으로 실패한 테스트(즉 레드 테스트)를 시작합니다. 클라우드 플랫폼 팀은 테스트에 통과할 때가지 각 기능 또는 수용 기준에 대한 개발 작업을 완료합니다(즉 그린 테스트).

TDD의 목표는 테스트 도구 모음을 만드는 것이 아니라 더 나은 디자인을 다루는 것입니다. 테스트는 프로세스를 완료하는 데 중요한 아티팩트입니다.

완료 정의

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

DoD는 클라우드 플랫폼 팀과 그 외 영향을 받는 팀 간의 약식 규약으로, 랜딩 존 개발 활동에 포함할 것으로 예상되는 부가가치 기능을 정의합니다. DoD는 단기 클라우드 채택 계획과 일치하는 체크리스트인 경우가 많습니다.

팀이 추가 워크로드 및 클라우드 기능을 채택함에 따라 DOD와 수용 기준은 점점 더 복잡해집니다. 성숙한 프로세스에서 예상되는 각 기능에는 명확성을 높일 수 있는 고유한 수용 기준이 있습니다. 모든 부가가치 기능이 수용 기준을 충족하면 현재 채택 단계 또는 릴리스가 성공을 거둘 수 있도록 랜딩 존이 충분히 구성됩니다.

간단한 DoD 예제

초기 마이그레이션 활동의 경우 DoD가 지나치게 간단할 수 있습니다. 다음은 간단한 DoD 예제입니다.

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

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

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

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

더 복잡한 DoD 예제

클라우드 채택 프레임워크 내의 거버넌스 방법론은 거버넌스 팀의 자연스러운 성숙을 통한 이야기 형식의 여정을 제공합니다. 그 경험에는 정책 성명의 형태로 DoD 및 수용 기준의 몇 가지 예가 포함되어 있습니다.

위의 예제는 랜딩 존에 대한 DoD를 개발하는 데 도움이 되는 기본 샘플입니다. 클라우드 거버넌스의 5개 분야 각각에 대한 샘플 정책을 가져올 수 있습니다.

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

다음 다이어그램에는 Azure에서 사용 가능한 테스트 기반 개발 도구가 나와 있습니다.

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

이러한 Azure 도구와 기능을 DoD에 손쉽게 통합하여 랜딩 존을 만들 수 있습니다. 도구는 TDD 주기에 맞춰 랜딩 존을 보다 쉽게 개발, 테스트하고 배포할 수 있도록 특정 용도로 사용됩니다.

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

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

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

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

    TDD 주기에서 정책 기준을 만들어 단일 수용 기준을 테스트할 수 있습니다. Azure Policy에는 DoD 내에서 개별 수용 기준을 충족할 수 있는 기본 제공 정책 정의가 포함되어 있습니다. 이 접근 방식에서는 랜딩 존을 수정하기 전에 레드 테스트 메커니즘을 제공합니다.

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

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

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

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

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

다음 단계