Amazon Web Services 한국 블로그

AWS 개발자 도구를 활용한 GitFlow 구현 방법

이 글에서는 AWS CodePipeline, AWS CodeCommit, AWS CodeBuild 및 AWS CodeDeploy를 사용하여 GitFlow를 구현하는 방법에 대한 높은 수준의 프레임워크를 제공하는 방법을 설명합니다. 이와 관련한 작업에 도움이 되는 AWS CloudFormation 템플릿과 AWS CLI 명령도 제공합니다.

시작하기 전에,  개발자가 이상적으로는 하루에도 여러 번 정기적으로 코드 변경을 중앙 리포지토리에 병합하는 “트렁크 기반 개발”을 통한 지속적 통합(CI)를 연습할 것을 권장드립니다. 개별 팀이 정기적으로 작은 변경 사항을 병합할 수 있게 되면, 향후 병합의 복잡성이 감소되고 관련 작업 부담도 줄어듭니다. 트렁크 기반의 지속적 통합을 지속적 전달(CD)과 결합하면 변경 사항을 프로덕션 환경에 적용하는 데 소요되는 시간이 감소됩니다.

뒷부분에서는 GitFlow에서는 마스터를 여러 수준으로 분기하고 기능 브랜치에 대한 변경이 주기적으로만 마스터에 병합되어 릴리스를 트리거합니다. “브랜치 기반 개발”을 사용하면 일반적으로 마스터로 병합되는 횟수가 줄고 “병합 부채”가 높은 수준으로 유지되므로 변경 사항을 프로덕션 환경에 적용하는 데 소요되는 시간이 늘어납니다.

물론, 모든 팀이 CI/CD의 높은 수준에 오른 것은 아닙니다. 많은 팀이 아직도 CI/CD 여정을 진행 중이거나 GitFlow와 같은 분기 모델이 더 유용한 상황(또는 필수적인 상황)에 놓여있을 수 있습니다. 이러한 이유로 인해 AWS에서는 AWS 도구를 사용하여 병합 및 출시 작업을 자동화하는 데 도움이 되는 정보를 제공하고자 합니다. 부연 설명을 마쳤으므로 바로 작업에 들어가 보겠습니다!

2005년 Linus Torvalds가 Git 버전 제어를 처름 소개했을 때, 개발 소스 분기 및 병합에 대해 생각하는 방식을 완전히 바꾸어 놓았습니다. Git 전에는 이러한 작업이 매우 까다로웠으며 가능하면 피해야 할 대상이었습니다. 도구가 발전함에 따라 분기 및 병합은 저렴하면서도 간결한 작업이 되었습니다. 이제 이러한 작업은 일상적인 개발 워크플로우의 일부로 자리잡았습니다. Vincent Driessen이 2010년에 소개한 GitFlow는 매우 유명한 분기 및 출시 관리 모델이 되었습니다. 이 모델은 메인라인 통합으로서의 develop 브랜치와 항상 프로덕션 준비 상태로 유지하는 것으로 잘 알려진 master 브랜치 개념을 도입했습니다. 마스터와 개발은 모두 영구 브랜치이지만 GitFlow는 수명이 짧은 feature, hotfix 및 release 브랜치의 사용도 권장하고 있습니다.

GitFlow 지침은 다음과 같습니다.

  • develop을 지속적 통합 브랜치로 사용합니다.
  • feature 브랜치를 사용하여 여러 기능에 대한 작업을 수행합니다.
  • release 브랜치를 사용하여 특정 릴리스에 대한 작업을 수행합니다(다중 기능).
  • master에서 분기된 hotfix 브랜치를 사용하여 핫픽스를 푸시합니다.
  • 매 출시 후 master로 병합합니다.
  • master는 프로덕션 준비 상태의 코드를 포함합니다.

배경에 대해 알아보았으므로 이제 AWS 개발자 도구에 포함된 서비스인 AWS CodePipeline, AWS CodeCommit, AWS CodeBuild 및 AWS CodeDeploy를 사용해 이 모델을 구현하는 방법을 살펴보겠습니다. 이 게시물에서는 여러분이 이러한 AWS 서비스에 대해 익숙한 것으로 가정합니다. 익숙하지 않은 경우 시작하기 전에 참고 자료 섹션의 링크를 참조하십시오. 또한 AWS CLI가 설치 및 구성되어 있다고 가정합니다.

주로 사용되는 GitFlow 도구를 게시물 전체에 걸쳐 사용할 것입니다. Git를 기반으로 작성된 이 도구는 브랜치 생성 및 병합 과정을 자동화합니다. 이 도구는 GitFlow 분기 모델 지침을 따릅니다. 이 도구를 사용하지 않아도 됩니다. 대신 Git 명령을 사용할 수도 있습니다.

간결한 설명을 위해 승인 또는 테스팅 단계를 포함하는 프로덕션급의 파이프라인은 생략하였지만 이러한 파이프라인도 이 모델에 쉽게 적용할 수 있습니다.  이상적인 프로덕션 시나리오에서는 개발 및 프로덕션 계정을 별도로 유지하기도 합니다.

AWS 개발자 도구 및 GitFlow

GitFlow로 AWS CodePipeline을 모델링하는 방법을 살펴보겠습니다. 브랜치별로 파이프라인을 생성하는 것이 핵심입니다. 각 파이프라인은 브랜치와 연관된 수명 주기를 가집니다. 수명이 짧은 새 브랜치를 생성할 때 해당 파이프라인과 필수 리소스를 생성합니다. 수명이 짧은 브랜치가 개발 환경에 병합된 후에는 비용 부과를 방지하기 위해 파이프라인과 리소스도 정리합니다.

다음 요소는 영구적이며 master 및 develp 브랜치와 동일한 수명을 가집니다.

  • AWS CodeCommit master/develop 브랜치
  • 모든 브랜치에 걸친 AWS CodeBuild 프로젝트
  • 모든 브랜치에 걸친 AWS CodeDeploy 애플리케이션
  • master(프로덕션) 및 devep(단계)를 위한 AWS Cloudformation 스택(EC2 인스턴스)

다음 요소는 일시적이며 수명이 짧은 브랜치와 동일한 수명을 가집니다.

  • AWS CodeCommit feature/hotfix/release 브랜치
  • 브랜치별 AWS CodePipeline
  • 브랜치별 AWS CodeDeploy 배포 그룹
  • 브랜치별 AWS Cloudformation 스택(EC2 인스턴스)

전체 구조는 다음과 같습니다.

기본 지침(EC2/온프레미스라고 가정):

  • 각 브랜치는 AWS CodePipeline을 가집니다.
  • AWS CodePipeline은 AWS CodeCommit가 소스 제공자로, AWS CodeBuild가 빌드 제공자로, AWS CodeDeploy가 배포 제공자로 구성됩니다.
  • AWS CodeBuild는 AWS CodePipeline이 소스로 구성됩니다.
  • 각 AWS CodePipeline은 배포를 위해 이름 태그를 사용하는 AWS CodeDeploy 배포 그룹을 가집니다.
  • 단일 Amazon S3 버킷이 아티팩트 스토어로 사용되지만 리포지토리 기반의 개별 버킷을 유지할 수 있습니다.

 

1 단계: 다음의 AWS CloudFormation 템플릿을 사용하여 커밋 리포지토리, VPC, EC2 인스턴스, CodeBuild, CodeDeploy 및 CodePipeline 등 master 및 develop 브랜치를 위한 필수 역할 및 환경을 설정합니다.

$ aws cloudformation create-stack --stack-name GitFlowEnv \
--template-body https://s3.amazonaws.com/devops-workshop-0526-2051/git-flow/aws-devops-workshop-environment-setup.template \
--capabilities CAPABILITY_IAM 


$ aws cloudformation create-stack --stack-name GitFlowCiCd \
--template-body https://s3.amazonaws.com/devops-workshop-0526-2051/git-flow/aws-pipeline-commit-build-deploy.template \
--capabilities CAPABILITY_IAM \
--parameters ParameterKey=MainBranchName,ParameterValue=master ParameterKey=DevBranchName,ParameterValue=develop

파이프라인은 CodePipeline 콘솔에 다음과 같이 표시됩니다.

 

 

 

 

2 단계: 콘텐츠를 AWS CodeCommit 리포지토리로 푸시합니다.

파일의 압축을 해제하고 리포지토리를 복제한 다음 콘텐츠를 커밋하여 CodeCommit – WebAppRepo로 푸시합니다.

3 단계: 리포지토리에서 git flow init을 실행하여 브랜치를 초기화합니다.

$ git flow init

새 feature에 대한 작업을 시작하고 브랜치를 생성해야 한다고 가정하겠습니다.

$ git flow feature start <branch>

4 단계: 스택을 업데이트하여 feature-x 브랜치에 대한 다른 파이프라인을 생성합니다.

$ aws cloudformation update-stack --stack-name GitFlowCiCd \
--template-body https://s3.amazonaws.com/devops-workshop-0526-2051/git-flow/aws-pipeline-commit-build-deploy-update.template \
--capabilities CAPABILITY_IAM \
--parameters ParameterKey=MainBranchName,ParameterValue=master ParameterKey=DevBranchName,ParameterValue=develop ParameterKey=FeatureBranchName,ParameterValue=feature-x

작업이 완료되면 CodePipeline 콘솔에서 feature-x 브랜치를 확인할 수 있습니다. 이 브랜치는 바로 구축 및 배포될 수 있습니다. 테스트를 하려면 브랜치에 변경을 수행하고 파이프라인의 동작을 관찰할 수 있습니다.

해당 브랜치가 예상한 대로 작동하는 것으로 확인하였으면 finish 명령을 사용하여 변경 사항을 develop 브랜치로 병합합니다.

$ git flow feature finish <feature>

변경 사항이 병합된 후, AWS CloudFormation 스택을 업데이트하여 브랜치를 제거합니다. 이렇게 하면 더 이상 필요하지 않은 리소스에 요금이 부과되는 것을 피할 수 있습니다.

$ aws cloudformation update-stack --stack-name GitFlowCiCd \
--template-body https://s3.amazonaws.com/devops-workshop-0526-2051/git-flow/aws-pipeline-commit-build-deploy.template \
--capabilities CAPABILITY_IAM \
--parameters ParameterKey=MainBranchName,ParameterValue=master ParameterKey=DevBranchName,ParameterValue=develop

release 및 hotfix 브랜치를 위한 과정도 이와 동일합니다.

최종 결과: 파이프라인 및 배포 그룹

최종적인 파이프라인의 모습은 다음과 같습니다.

다음 단계

CLI 명령을 자체 사용자 지정 bash 스크립트로 작성하는 경우, GitFlow와 스크립트를 사용하여 수명이 짧은 브랜치를 위한 파이프라인과 리소스를 빠르게 설정 및 해체할 수 있습니다. 이 기능은 더 이상 필요하지 않은 리소스에 요금이 부과되는 것을 피하는 데 도움이 됩니다. 또는, Lambda 함수를 작성하여 생성 날짜를 기반으로 정기적으로 수명이 짧은 파이프라인을 삭제하도록 예약할 수도 있습니다.

요약

이 블로그 게시물에서는 AWS CodePipeline, AWS CodeCommit, AWS CodeBuild 및 AWS CodeDeploy를 사용하여 GitFlow를 모델링하는 방법을 살펴 보았습니다. 특히 개발자분들이 feature/release/hotfix 브랜치 작업을 수행하고 협업, 테스트 및 배포 변경을 빠르게 수행할 있는 환경을 제공하기 위해 CI/CD 전략을 개선하는 데 이 게시물의 정보가 도움이 될 수 있기를 바랍니다.

참고 자료

– Ashish Gore;

이 글은 AWS DevOps 블로그의 Implementing GitFlow Using AWS CodePipeline, AWS CodeCommit, AWS CodeBuild, and AWS CodeDeploy의 한국어 번역으로 AWS 테크니컬 어카운트 매니저인 김순근님이 감수하였습니다.