AWS CodePipeline를 활용한 브랜치 기반 개발 및 모노레포 구성하기

이 글은 AWS DevOps Blog에 게시된 AWS CodePipeline adds support for Branch-based development and Monorepos를 한국어로 번역 및 편집하였습니다.

AWS CodePipeline 은 애플리케이션 및 인프라 업데이트를 위해 릴리스 파이프라인을 자동화하는 관리형 지속적 배포 서비스입니다. 현재 CodePipeline은 다양한 배포 전략을 갖춘 팀을 지원하기 위해 트리거와 새로운 실행 모드를 추가하였습니다. 이 기능들은 고객이 파이프라인을 구축할 때 더 다양한 선택을 가능하게 합니다.

이 블로그에서는 트리거와 파이프라인 실행 모드를 함께 사용하여 세 가지 파이프라인을 디자인하는 방법을 안내합니다. 이러한 예제는 브랜치 기반 개발을 실행하거나 모노레포 내에서 여러 프로젝트를 관리하는 고객에게 필요할 것입니다.

• Pipeline #1: GitFlow(멀티 브랜치) 릴리스 파이프라인을 생성합니다.
• Pipeline #2: 모든 풀 리퀘스트(PR)에 대해 파이프라인을 실행합니다.
• Pipeline #3: 모노레포 내의 단일 폴더에서 파이프라인을 실행합니다.

각 파이프라인을 살펴보고 이러한 기능과 사용 방법에 대해 자세히 알아보겠습니다. 여러분은 실습을 완료한 후 트리거 및 실행 모드를 사용하여 이러한 예제를 파이프라인 요구 사항에 맞게 조정할 수 있습니다.

Pipeline#1 – GitFlow(멀티 브랜치) 릴리스 파이프라인 생성

GitFlow 는 long-running브랜치를 사용하여 병렬 개발 및 릴리스로 대규모 프로젝트를 관리하는 개발 모델입니다. GitFlow는 feature, release 및 hotfix 브랜치와 함께 두 개의 영구 브랜치인 main 및 develop을 사용합니다. 여러 브랜치에서 파이프라인을 트리거하는 방법을 다루므로 이러한 개념을 적용하면 GitHub flow같은 다른 멀티 브랜치 파이프라인 전략을 단순화할 수 있습니다.

AWS Management Console, AWS CLI, AWS CloudFormation을 사용하거나 CodePipeline CreatePipeline API를 호출하는 코드를 작성하여 파이프라인을 생성할 수 있습니다. 이 블로그에서는 release 파이프라인과 feature develop 파이프라인이라는 두 가지 파이프라인을 만들어보겠습니다. 먼저 CodePipeline 콘솔로 이동하여 파이프라인 생성을 선택합니다.

첫번째 단계입니다. 파이프라인 설정에서는 아래 그림 1과 같이 새로 추가된 실행 모드인 Queued및 Parallel에 대한 옵션이 표시됩니다.

그림 1.  실행 모드에 대한 GitFlow 릴리스 파이프라인 설정의 예입니다.

파이프라인의 실행 모드에 따라 여러 실행 처리가 결정됩니다:

• Superseded– 최근에 시작된 실행이 이전에 시작된 실행을 따라잡을 수 있습니다. 이전의 CodePipeline은 Superseded 실행 모드만 지원했습니다.
• Queued– 실행은 Queue에 대기하며 이미 시작된 실행을 따라잡지 않습니다. 실행은 Queue에 있는 순서대로 하나씩 처리됩니다.
• Parallel– 실행은 서로 독립적이며 다른 실행이 완료될 때까지 기다리지 않습니다.

첫 번째 파이프라인인 release파이프라인은 main, develop, hotfix 및 release 브랜치에서 트리거 됩니다. 파이프라인은 트리거된 순서대로 브랜치에 대한 모든 푸시를 실행해야하기 때문에 Queue를 선택합니다. 선택한 파이프라인 유형이 V2인지 확인하고 다음을 클릭합니다.

그림 2. 소스 연결 및 레포지토리 예시

두번재 단계인 소스 추가 단계에서는 소스 공급자, 연결, 리포지토리 이름 및 Default 브랜치를 설정합니다. 이 예에서는 GitHub를 사용하므로 소스공급자에서GitHub에 연결을 선택합니다. 연결은 GitHub와 같은 타사 공급자를 CodePipeline과 연결하는 구성을 승인하고 설정합니다.

이제 소스 설정이 완료되었으므로 트리거를 구성하겠습니다. 트리거는 코드 푸시 또는 풀 리퀘스트와 같이 파이프라인을 시작하는 이벤트 유형을 정의합니다. 필터링된 트리거를 추가해야하기 때문에 트리거 유형에서 필터 지정을 선택합니다.

이 파이프라인에서는 이벤트 유형으로 푸시를 선택합니다. 푸시 트리거는 변경 사항이 소스 리포지토리에 푸시될 때 파이프라인을 시작합니다. 실행에서는 푸시되는 브랜치, 즉 대상 브랜치의 파일을 사용합니다. 다음으로 필터 유형으로 Branch를 선택합니다. 브랜치 필터 유형은 실행 시작 시기를 알기 위해 트리거가 모니터링하는 GitHub 연결 저장소의 브랜치를 지정합니다.

브랜치 필터에는 두가지 유형이 있습니다. :

• Include– 브랜치 이름이 패턴과 일치하면 트리거가 파이프라인을 시작합니다.
• Exclude– 브랜치 이름이 패턴과 일치하면 트리거가 파이프라인을 시작하지 않습니다.

참고: Include및 Exclude모두 동일한 패턴을 갖는 경우 기본값은 Exclude 패턴입니다.

브랜치 패턴은 glob형식으로 입력됩니다. glob 패턴에서 동작을 트리거 할 브랜치를 지정하기 위해 Include에 main,develop,hotfix/**,release/**를 입력하고 Exclude를 비워 둡니다.

그림3. 푸시 이벤트 유형 및 브랜치필터에 대한 GitFlow 릴리스 파이프라인의 예입니다.

필터 구성을 완료하고 다음을 클릭합니다.

우리는 초점을 애플리케이션이 아닌 파이프라인에 유지하기 위해 파이프라인 생성으로 건너뛰겠습니다. 이 예제의 애플리케이션 및 빌드 단계는 AWS CodeBuild가 AWS Lambda 컴퓨팅 모드에 대한 지원을 추가하는 예제를 참조하였습니다.

이번에는 feature develop 파이프라인을 생성하겠습니다. feature develop파이프라인은 feature 브랜치에서 트리거됩니다. 다른 feature branch에서 작업하는 동료에 의해 트리거가 블로킹되어서는 안 되므로 Parallel 실행 모드를 선택합니다. 선택한 파이프라인 유형이 V2인지 확인하고 다음을 클릭합니다.

그림4. Parallel 실행 모드에 대한 GitFlow feature 파이프라인 설정의 예입니다.

소스단계의 소스 공급자와 연결은 이전 릴리스 파이프라인과 동일하게 설정됩니다. 위의 그림 2를 참조하세요. 소스 단계가 완료되면 이벤트 유형 푸시로 트리거를 하는데 이번에는 include에 feature/**만 입력합니다.

그림5. 푸시 이벤트 유형 및 브랜치 필터에 대한 GitFlow feature 파이프라인의 예입니다.

필터 구성을 마쳤으며 파이프라인 생성으로 건너뜁니다.

파이프라인 생성이 완료되면 앞서 생성한 두 파이프라인, 즉 릴리스 파이프라인과 feature develop 파이프라인을 모두 볼 수 있습니다.

그림 6. GitFlow 파이프라인 예시

파이프라인 설정을 확인하기 위해 여러 코드 변경 사항을 생성하고 feature 브랜치와 release 브랜치(develop, release, main)에 병합합니다. 이제 파이프라인 화면에는 일치하는 브랜치에 의해 트리거된 실행이 표시됩니다. 파이프라인이 이러한 실행을 어떻게 Queue에 성공적으로 추가했는지 확인하세요.

그림7. 대기 중인 GitFlow 릴리스 실행 예시

지금까지 GitFlow 릴리스 파이프라인을 구현했습니다. 이제 브랜치 필터 유형과 푸시 이벤트 트리거를 사용하면 이 예제를 확장하여 브랜치 기반 개발 요구 사항을 충족할 수 있습니다.

Pipeline #2 – 모든 풀 리퀘스트(PRs)에 파이프라인 실행하기

시작하기 전, Pipeline #1에서 다룬 개념을 검토하고 해당 내용을 바탕으로 빌드하는 것이 좋습니다.

풀 리퀘스트(PR)에서 파이프라인을 트리거하는 것은 PR이 브랜치에 병합되기 전, 빌드 및 테스트 실패를 포착하기 위한 일반적인 연속 통합 패턴입니다. PR 파이프라인은 보안 스캔, 검증 테스트 또는 성능 테스트와 같은 테스트를 모든 커밋에서 실행하는 대신 PR의 변경 사항으로 제한하여 전체 릴리스보다 더 빠르고 가벼운 경우가 많습니다. 모든 PR에 대해 단일 파이프라인을 트리거하면 병합하기 전에 저장소에 제안된 변경 사항을 검토하고 검증할 수 있습니다.

파이프라인 생성을 시작하려면 Create Pipeline을 클릭하여 새 파이프라인을 생성합니다. 실행 모드를 Parallel로 변경합니다. 개발팀이 동시에 여러 기능을 작업하고 있는데 다른 실행이 완료될 때까지 기다리는 것은 낭비이기 때문에 Parallel을 선택합니다. 선택한 파이프라인 유형이 V2인지 확인하고 다음을 클릭합니다.

그림8. Parallel실행 모드에 대한 PR 파이프라인 설정 예

이전 파이프라인과 같이 소스 공급자 및 연결은 위의 그림 2에 표시된 대로 설정합니다. 소스 단계가 설정되면 Pull Request Trigger를 구성합니다.

이 파이프라인에서는 이벤트 유형으로 Pull Request를 선택합니다. 풀 리퀘스트 트리거는 풀 리퀘스트가 소스 리포지토리에서 열리거나, 업데이트되거나, 닫힐 때 파이프라인을 시작합니다. 실행에서는 변경 사항을 가져오는 브랜치, 즉 소스 브랜치의 파일을 사용합니다. 다음으로, Pull request is Created 와New revision is made to pull request for Events for pull request를 선택합니다. 모든 브랜치에 대한 풀 리퀘스트를 일치시키려면  Include에 **를 입력하고 Exclude 를 비워 둡니다.

그림 9. 풀 리퀘스트이벤트 유형에 대한 PR 파이프라인의 예입니다.

Pipeline #1에서 했던 것과 유사하게 빌드 및 배포 단계의 세부 정보를 건너뛰고 파이프라인 생성으로 빠르게 이동하겠습니다.

파이프라인 생성이 완료되면 테스트로 GitHub 저장소에서 몇 가지 PR을 생성합니다. CodePipeline으로 돌아가 파이프라인을 클릭하면 파이프라인의 실행 기록 화면으로 바로 이동하는 것을 볼 수 있습니다. 실행 기록으로 리디렉션되는 이유는 파이프라인 실행 모드가 병렬이고 모든 실행이 독립적이기 때문입니다. 이 화면에는 파이프라인을 트리거한 각 풀 리퀘스트에 대한 세부 정보를 표시하는 트리거들이 표시됩니다.

그림10. parallel실행이 포함된 PR 파이프라인의 예

참고: 개별 실행 파이프라인을 보려면 실행 ID를 클릭하세요.

지금까지 브랜치의 모든 PR에 대해 PR 유효성 검사 파이프라인을 구현했습니다. 풀 리퀘스트 이벤트 트리거 및 브랜치 필터 유형을 사용하면 이제 PR 파이프라인 요구 사항을 충족하도록 구성 할 수 있습니다.

Pipeline #3 – 모노레포 내의 단일 폴더에서 파이프라인 실행

시작하기 전, Pipeline #1에서 다룬 개념을 검토하고 해당 내용을 바탕으로 빌드하는 것이 좋습니다.

모노레포는 단일 저장소를 사용하여 여러 프로젝트의 코드를 포함하는 소프트웨어 개발 전략입니다. 모든 커밋에서 단일 저장소에 포함된 각 프로젝트에 대해 파이프라인을 실행하는 것은 비효율적이며, 특히 각 프로젝트에 서로 다른 파이프라인이 필요한 경우 더욱 그렇습니다. 이 파이프라인 예제에서는 파이프라인 실행을 main 브랜치의 infrastructure 폴더 내부 변경으로만 제한하고 있습니다. 이를 통해 비용을 절감하고 배포 속도를 높이며 리소스 사용을 최적화할 수 있습니다.

먼저 Create Pipeline을 클릭하여 새 파이프라인을 생성합니다. 이 예에서는 특정 실행 모드 요구 사항이 없으므로 기본 실행 모드를 Superseded으로 유지합니다. 선택한 파이프라인 유형이 V2인지 확인하고 다음을 클릭합니다.

이전 파이프라인과 같이 소스 공급자 및 연결은 위의 그림 2를 따라 설정합니다. 소스 단계가 완료되면 main 브랜치의  infrastructure 폴더에서 트리거 할 수 있도록 구성합니다.

이 파이프라인에서는 이벤트 유형으로 푸시를 선택합니다. 다음으로 필터 유형에서 Branch를 선택합니다. 푸시를 main에만 일치시키려면 브랜치에 대한 Include 아래에 main을 입력하고 exclude를 비워 둡니다. 파일 경로 아래의 포함에 infrastructure/**를 입력하고 exclude를 비워 둡니다. 파일 경로 필터 유형은 실행 시작 시기를 알기 위해 트리거가 모니터링하는 소스 저장소의 파일 경로 이름을 지정합니다. 브랜치 필터와 마찬가지로 Include 및 exclude 에서 glob 형식으로 파일 경로 이름 패턴을 지정할 수 있습니다.

그림11. 푸시 이벤트 유형 및 파일 경로 필터에 대한 예시 모노레포 파이프라인

필터 구성이 완료되었으므로 다음을 클릭합니다.

Pipeline #1에서 했던 것처럼 빌드 및 배포 단계의 세부 정보를 생략하고 파이프라인 생성으로 이동하겠습니다.

파이프라인이 생성되면 infrastructure폴더 내부 및 외부의 main 브랜치를 변경하여 GitHub에서 파이프라인 트리거를 테스트할 수 있습니다. 인프라 폴더 내의 파이프라인만 호출하는지 확인하기 위해 CodePipeline에서 파이프라인에 대한 기록을 엽니다. Infrastructure의 변경사항만 실행되고 있음을 확인합니다.

그림12. Infrastructure변경 실행만 포함된 모노레포 파이프라인 예시

이렇게 모노레포의 저장소 변경 사항을 기반으로 파이프라인을 선택적으로 호출했습니다. 이제 파일 경로 필터 유형을 사용하여 이 예제를 확장하면 모노레포 릴리스 파이프라인을 구성 할 수 있습니다.

결론

AWS CodePipeline의 새로운 트리거 및 실행 모드는 AWS에서 파이프라인을 구축하기 위한 새로운 패턴을 제공합니다. 이 게시물에서는 구축할 수 있는 새로운 기능과 세 가지 인기 파이프라인 패턴에 대해 논의했습니다. GitFlow 또는 멀티 브랜치 전략을 생성하는 경우 CodePipeline은 멀티 브랜치 모델에 대한 릴리스 파이프라인 관리를 단순화합니다. 모노레포에 파일 경로 필터 유형을 사용하든 Parallel 실행 모드를 활용하여 개발자 블로킹을 해제하든 CodePipeline은 소프트웨어 개발 프로세스를 가속화합니다. 지금 AWS CodePipeline 사용 설명서와 실습 튜토리얼을 확인하여 배포 워크플로를 자동화하세요.