View a markdown version of this page

IaC에 대한 분기 전략 - AWS 권장 가이드

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

IaC에 대한 분기 전략

일반적인 Git 방법론은 프로덕션, 개발 브랜치 및 기능 브랜치에 기본 트렁크 베이스(예: main) 브랜치를 사용합니다. 많은 조직이 코드형 인프라(IaC)에 대해 이와 동일한 설계를 즉시 채택합니다. 그러나 Git 방법론은 일반적인 인프라 설계 패턴과 직접 호환되지 않습니다. 다음 사항을 고려하세요.

  • 애플리케이션에는 여러 환경이 있습니다.

    • 환경 예제에는 샌드박스, 개발, 스테이징 및 프로덕션이 포함됩니다.

  • 환경은 긴밀하게 결합되지 않습니다.

    • 프로덕션은 성공적인 스테이징 배포와 긴밀하게 결합되는 경우가 많습니다.

    • 프로덕션 및 스테이징은 일반적으로 개발 환경에서 완전히 분리됩니다.

    • 개발은 일반적으로 샌드박스 환경에서 완전히 분리됩니다.

  • 각 애플리케이션에는 고유한 환경 표준 세트가 있습니다.

    • 많은 애플리케이션은 샌드박스 환경을 사용하지 않습니다.

    • 일부 애플리케이션에는 스테이징 환경이 필요하지 않지만 대신 블루/그린 배포 전략을 사용합니다.

애플리케이션 리포지토리가 트렁크 기반 방법론을 사용하는 세 가지 환경을 제공하는 시나리오를 가정해 보겠습니다. 개발 환경은 develop브랜치, 스테이징은 staging브랜치, 프로덕션은 브main랜치에 연결됩니다. 이 애플리케이션의 경우 다른 팀 및 리포지토리에서 관리하는 솔루션의 전송 게이트웨이를 연결하려면 새 기능이 필요합니다. 개발자는 특성 브랜치에 인프라 코드를 작성하고 준비가 되면 이를 develop브랜치에 병합합니다. 모두 잘 나타납니다.

하지만 문제가 발생합니다. 다른 개발자는 별도의 기능에 대한 별도의 사용자 스토리를 가지고 있으며, 이를 기능 브랜치에 쓰고 브develop랜치에 병합합니다. 이제 두 번째 기능을 스테이징 및 프로덕션에 병합할 준비가 되었습니다. 그러나 조직의 위험 기준으로 인해 원래 전송 게이트웨이 기능은 준비되지 않습니다. 이제 모든 기능이 프로덕션으로 승격되지 않으며 애플리케이션 코드가 효과적으로 고정되거나 중단됩니다.

이 시나리오에서는 다음과 같은 잠재적 솔루션을 고려하세요.

  • 가장 일반적인 솔루션: 리포지토리에 별도의 ./environments 폴더를 설정하여 대상 코드 구조 위치에서 코드 반복을 늘립니다(DRY 감소). 이렇게 하면 환경의 코드가 동일한 리포지토리에 있지만 분리될 수 있습니다.

  • 복잡한 변수 관리를 사용하여 CI/CD 프로세스를 설정합니다.

  • 환경을 별도의 리포지토리로 분리합니다.

  • 최소 공통 솔루션: 여러 트렁크 브랜치를 사용합니다.