# 지속적 통합 및 지속적 전달 구현
이 단원에서는 조직에서 CI/CD 모델을 구현할 수 있는 방법에 대해 설명합니다. 이 백서에서는 완성된 DevOps 및 클라우드 전환 모델을 갖춘 조직이 CI/CD 파이프라인을 구축하고 사용하는 방법에 대해서는 다루지 않습니다. DevOps 여정을 돕고자 AWS에는 리소스와 도구를 제공할 수 있는 다수의 [DevOps 인증 파트너](https://aws.amazon.com/devops/partner-solutions/)가 있습니다. AWS 클라우드로의 전환을 준비하는 방법에 대한 자세한 내용은 [클라우드 운영 모델 구축](https://d1.awsstatic.com/whitepapers/building-a-cloud-operating-model.pdf)을 참조하십시오.
# 지속적 통합/지속적 전달을 위한 경로
CI/CD는 파이프라인(다음 그림 참조) 으로 나타낼 수 있으며, 여기서 새 코드는 한쪽 끝에서 제출되고 일련의 단계(소스, 빌드, 스테이징 및 프로덕션)를 걸쳐 테스트된 다음 프로덕션 준비 코드로 게시됩니다. CI/CD를 처음 사용하는 조직의 경우 반복적인 방식으로 이 파이프라인에 접근할 수 있습니다. 즉, 소규모로 시작하여 각 단계에서 반복해야 조직의 성장에 도움이 되는 방식으로 코드를 이해하고 개발할 수 있습니다.
![\[CI/CD 파이프라인\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/image2.png)
*CI/CD 파이프라인*
CI/CD 파이프라인의 각 단계는 전달 프로세스에서 논리적 단위로 구성됩니다. 또한 각 단계는 코드의 특정 측면을 확인하는 게이트 역할을 합니다. 파이프라인을 통해 코드가 진행됨에 따라 코드의 더 많은 측면이 계속 검증되기 때문에 이후 단계에서 코드 품질이 더 높다고 가정됩니다. 초기 단계에서 발견된 문제로 인해 코드가 파이프 라인을 통해 진행되지 않습니다. 테스트 결과는 즉시 팀으로 전송되며, 소프트웨어가 단계를 통과하지 못하면 이후의 모든 빌드 및 릴리스가 중지됩니다.
이 단계들은 제안 사항입니다. 비즈니스 요구 사항에 따라 단계를 조정할 수 있습니다. 여러 유형의 테스트, 보안 및 성능에 대해 일부 단계를 반복할 수 있습니다. 프로젝트의 복잡성과 팀 구조에 따라 일부 단계를 다른 수준에서 여러 번 반복할 수 있습니다. 예를 들어 한 팀의 최종 제품이 다음 팀의 프로젝트에 종속될 수 있습니다. 즉, 첫 번째 팀의 최종 제품은 이후 다음 팀의 프로젝트에서 아티팩트로 준비됩니다.
CI/CD 파이프라인이 있으면 조직의 역량 향상에 큰 영향을 미칩니다. 조직은 처음부터 여러 환경, 많은 테스트 단계 및 모든 단계의 자동화를 통해 완전한 파이프라인을 구축하려 하지 말고 작은 단계부터 시작해야 합니다. CI/CD 환경의 완성도가 높은 조직도 파이프라인을 지속적으로 개선해야 합니다.
CI/CD를 지원하는 조직을 구축하는 것은 하나의 여정이며, 그 과정에는 여러 목표가 있습니다. 다음 단원에서는 지속적 전달 수준을 통한 지속적 통합부터 시작하여 조직에서 취할 수 있는 가능한 경로에 대해 설명합니다.
# 지속적 통합
![\[alt text not found\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/cd-source-and-build.png)
*지속적 통합 - 소스 및 빌드 *
CI/CD 여정의 첫 번째 단계는 지속적 통합의 완성도를 개발하는 것입니다. 모든 개발자가 정기적으로 코드를 중앙 리포지토리(예: CodeCommit 또는 GitHub에서 호스팅되는 항목)에 커밋하고 모든 변경 사항을 애플리케이션의 릴리스 분기에 병합해야 합니다. 어떤 개발자도 코드를 따로 보관해서는 안 됩니다. 일정 기간 동안 기능 분기가 필요한 경우, 가능한 한 자주 업스트림에서 병합하여 최신 상태로 유지해야 합니다. 팀이 규율을 개발하고 그 과정을 통해 더욱 힘을 얻을 수 있도록 전체 작업 단위와 자주 커밋하고 병합하는 것이 좋습니다. 개발자가 코드를 초기에 자주 병합하면 향후 통합 문제가 줄어들 가능성이 높습니다.
또한 개발자가 애플리케이션에 대한 단위 테스트를 최대한 일찍 만들고 코드를 중앙 리포지토리에 푸시하기 전에 이러한 테스트를 실행하도록 권장해야 합니다. 소프트웨어 개발 프로세스 초기에 발견된 오류가 가장 저렴하고 쉽게 수정할 수 있습니다.
코드가 소스 코드 리포지토리의 분기로 푸시되면 해당 분기를 모니터링하는 워크플로 엔진이 빌더 도구로 명령을 보내 코드를 빌드하고 제어된 환경에서 단위 테스트를 실행합니다. 빠른 피드백을 위해 커밋 단계에서 발생할 수 있는 푸시 및 테스트를 포함한 모든 활동을 처리할 수 있도록 빌드 프로세스의 크기를 적절하게 조정해야 합니다. 단위 테스트 적용 범위, 스타일 체크 및 정적 분석과 같은 다른 품질 검사도 이 단계에서 수행될 수 있습니다. 마지막으로, 빌더 도구는 하나 이상의 바이너리 빌드와 기타 아티팩트(예: 이미지, 스타일시트 및 애플리케이션 문서)을 생성합니다.
# 지속적 전달: 스테이징 환경 만들기
![\[alt text not found\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/cd-staging.png)
*지속적 전달 - 스테이징*
지속적 전달(CD)은 다음 단계이며, 프로덕션 스택의 복제본인 스테이징 환경에 애플리케이션 코드를 배포하고 더 많은 기능 테스트를 실행해야 합니다. 스테이징 환경은 테스트용으로 미리 만들어진 정적 환경이거나 애플리케이션 코드를 테스트하고 배포하기 위해 커밋된 인프라 및 구성 코드로 동적 환경을 프로비저닝하고 구성할 수 있습니다.
# 지속적 전달: 프로덕션 환경 생성
![\[alt text not found\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/cd-production.png)
*지속적 전달 - 프로덕션*
배포/제공 파이프라인 순서에서 스테이징 환경 이후의 프로덕션 환경은 코드형 인프라(IaC)를 사용하여 구축됩니다.
# 지속적 배포
![\[alt text not found\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/cd-cd.png)
*지속적 배포*
CI/CD 배포 파이프라인의 마지막 단계는 지속적 배포이며, 여기에는 프로덕션 환경에 대한 배포를 포함하여 전체 소프트웨어 릴리스 프로세스의 전체 자동화가 포함될 수 있습니다. 완성된 CI/CD 환경에서는 프로덕션 환경으로 가는 경로가 완전히 자동화되어 코드를 매우 안정적으로 배포할 수 있습니다.
# 기대를 뛰어넘는 완성도
조직이 성장함에 따라 다음과 같은 개선 사항을 더 많이 포함하도록 CI/CD 모델을 계속 개발할 것입니다.
+ 특정 성능, 규정 준수, 보안 및 UI(사용자 인터페이스) 테스트를 위한 더 많은 스테이징 환경
+ 애플리케이션 코드와 함께 인프라 및 구성 코드의 단위 테스트
+ 코드 검토, 문제 추적 및 이벤트 알림과 같은 다른 시스템 및 프로세스와의 통합
+ 데이터베이스 스키마 마이그레이션과 통합(해당되는 경우)
+ 감사 및 비즈니스 승인을 위한 추가 단계
복잡한 다중 환경 CI/CD 파이프라인을 갖춘 완성도가 높은 조직도 계속해서 개선을 모색하고 있습니다. DevOps는 목적지가 아닌 여정입니다. 파이프라인에 대한 피드백을 지속적으로 수집하고 개발 팀의 여러 부서 간의 협업을 통해 속도, 규모, 보안 및 안정성을 개선합니다.
# 팀
AWS에서는 CI/CD 환경을 구현하기 위해 애플리케이션 팀, 인프라 팀, 도구 팀 등 세 개의 개발자 팀을 구성할 것을 권장합니다(다음 그림 참조). 이 조직은 빠르게 변화하는 스타트업, 대기업 및 Amazon 자체에서 개발되고 적용된 일련의 모범 사례를 나타냅니다. 팀은 피자 두 판 규모의 그룹 또는 약 10\$112명보다 크지 않아야 합니다. 이는 그룹 규모가 증가하고 소통이 늘어남에 따라 의미있는 대화가 한계에 도달한다는 통신 규칙을 따릅니다.
![\[alt text not found\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/image7.png)
*애플리케이션, 인프라 및 도구 팀*
## 애플리케이션 팀
애플리케이션 팀에서 애플리케이션을 생성합니다. 애플리케이션 개발자는 백로그, 스토리 및 단위 테스트를 소유하며 지정된 애플리케이션 대상을 기반으로 기능을 개발합니다. 이 팀의 조직 목표는 개발자들이 비핵심 애플리케이션 작업에 소비하는 시간을 최소화하는 것입니다.
애플리케이션 팀은 애플리케이션 언어로 함수 프로그래밍 기술을 보유하는 것 외에도 플랫폼 기술과 시스템 구성에 대한 이해도 갖추어야 합니다. 이를 통해 기능 개발 및 애플리케이션 강화에만 집중할 수 있습니다.
## 인프라 팀
인프라 팀은 애플리케이션을 실행하는 데 필요한 인프라를 만들고 구성하는 코드를 작성합니다. 이 팀은 AWS CloudFormation과(와) 같은 기본 AWS 도구나 Chef, Puppet 또는 Ansible과 같은 일반 도구를 사용할 수 있습니다. 인프라 팀은 필요한 리소스를 지정할 책임이 있으며 애플리케이션 팀과 긴밀하게 협력합니다. 인프라 팀은 소규모 애플리케이션을 위해 한두 명으로만 구성될 수 있습니다.
팀은 AWS CloudFormation 또는 HashiCorp Terraform과 같은 인프라 프로비저닝 방법에 대한 기술을 갖추어야 합니다. 또한 팀은 Chef, Ansible, Puppet 또는 Salt와 같은 도구를 사용하여 구성 자동화 기술을 개발해야 합니다.
## 도구 팀
도구 팀은 CI/CD 파이프라인을 구축하고 관리합니다. 파이프라인을 구성하는 인프라와 도구를 담당합니다. 피자 두 판 규모의 팀에 속하지는 않지만, 조직의 애플리케이션 및 인프라 팀에서 사용하는 도구를 만듭니다. 조직은 완성도가 높은 애플리케이션 및 인프라 팀보다 도구 팀이 한 발 앞서 나갈 수 있도록 도구 팀을 지속적으로 발전시켜야 합니다.
도구 팀은 CI/CD 파이프라인의 모든 부분을 구축하고 통합하는 데 능숙해야 합니다. 여기에는 소스 제어 리포지토리, 워크플로 엔진, 빌드 환경, 테스트 프레임워크 및 아티팩트 리포지토리의 구축이 포함됩니다. 이 팀은 Jenkins, GitHub, Artifactory, TeamCity 및 기타 유사한 도구와 함께 AWS CodeStar, AWS CodePipeline, AWS CodeCommit, AWS CodeDeploy, AWS CodeBuild 및 AWS CodeArtifact 등의 소프트웨어를 구현할 수 있습니다. 일부 조직에서는 이를 DevOps 팀이라고 부를 수 있지만, AWS은(는) 이를 권장하지 않고 대신 DevOps를 소프트웨어 제공의 인력, 프로세스 및 도구의 총합으로 간주할 것을 권장합니다.
# 지속적 통합 및 지속적 전달의 테스트 단계
세 개의 CI/CD 팀은 CI/CD 파이프라인의 여러 단계에서 소프트웨어 개발 수명 주기에 테스트를 통합해야 합니다. 전반적으로 테스트는 최대한 빨리 시작해야 합니다. 다음 테스트 피라미드는 Mike Cohn이 *Agile로 거둔 성과*에서 제공하는 개념입니다. 실행 비용 및 속도와 관련된 다양한 소프트웨어 테스트가 표시됩니다.
![\[alt text not found\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/image8.png)
* CI/CD 테스트 피라미드 *
단위 테스트는 피라미드 맨 아래에 있습니다. 실행 속도가 가장 빠르고 비용도 가장 저렴합니다. 따라서 단위 테스트가 테스트 전략의 대부분을 차지해야 합니다. 경험상 약 70%를 차지하는 것이 좋습니다. 이 단계에서 잡은 버그는 빠르고 저렴하게 수정할 수 있기 때문에 단위 테스트의 코드 적용 범위는 거의 완전해야 합니다.
서비스, 구성 요소 및 통합 테스트는 피라미드의 단위 테스트 위에 있습니다. 이러한 테스트에는 상세한 환경이 필요하므로 인프라 요구 사항에 더 많은 비용이 들고 실행 속도가 느려집니다. 다음 단계는 성능 및 규정 준수 테스트입니다. 이 테스트에는 프로덕션 품질 환경이 필요하며 아직 더 비쌉니다. UI 및 사용자 승인 테스트는 피라미드의 최상위에 있으며 프로덕션 품질 환경도 필요합니다.
이 모든 테스트는 고품질 소프트웨어를 보장하기 위한 전체 전략의 일부입니다. 그러나 개발 속도를 위해서는 피라미드 아래쪽의 테스트 횟수와 적용 범위에 중점을 둡니다.
다음 단원에서는 CI/CD 단계에 대해 설명합니다.
## 소스 설정
프로젝트를 시작할 때는 원시 코드와 구성 및 스키마 변경 사항을 저장할 수 있는 소스를 설정해야 합니다. 소스 단계에서 GitHub 또는 AWS CodeCommit에서 호스팅되는 소스 코드 리포지토리와 같은 소스 코드를 선택합니다.
## 빌드 설정 및 실행
빌드 자동화는 CI 프로세스에 필수입니다. 빌드 자동화를 설정할 때 첫 번째 작업은 올바른 빌드 도구를 선택하는 것입니다. 다음과 같은 여러 빌드 도구가 있습니다.
+ Java용 Ant, Maven 및 Gradle
+ C/C\$1\$1용 Make
+ JavaScript용 Grunt
+ Ruby용 Rake
사용자에게 가장 적합한 빌드 도구는 프로젝트의 프로그래밍 언어와 팀의 기술 집합에 따라 다릅니다. 빌드 도구를 선택한 후에는 빌드 단계와 함께 빌드 스크립트에서 모든 종속성을 명확하게 정의해야 합니다. 또한 최종 빌드 아티팩트의 버전을 관리하는 것이 가장 좋으며, 이렇게 하면 배포가 더 쉬워지고 문제를 추적할 수 있습니다.
## 빌드
빌드 단계에서 빌드 도구는 소스 코드 리포지토리에 대한 변경 사항을 입력으로 받아 소프트웨어를 빌드하고 다음 유형의 테스트를 실행합니다.
**단위 테스트 –** 코드의 특정 섹션을 테스트하여 코드가 예상대로 작동하는지 확인합니다. 단위 테스트는 개발 단계에서 소프트웨어 개발자가 수행합니다. 이 단계에서는 정적 코드 분석, 데이터 흐름 분석, 코드 적용 범위 및 기타 소프트웨어 검증 프로세스를 적용할 수 있습니다.
**정적 코드 분석 –** 이 테스트는 빌드 및 단위 테스트 후 애플리케이션을 실제로 실행하지 않고 수행됩니다. 이 분석은 코딩 오류와 보안 허점을 찾는 데 도움이 될 수 있으며 코딩 지침을 준수하는지 확인할 수 있습니다.
## 스테이징
스테이징 단계에서는 최종 프로덕션 환경을 반영하는 전체 환경이 생성됩니다. 다음 테스트가 수행됩니다.
**통합 테스트** – 소프트웨어 설계와 비교하여 구성 요소 간의 인터페이스를 검증합니다. 통합 테스트는 반복적인 프로세스이며 강력한 인터페이스 및 시스템 무결성을 쉽게 구축할 수 있습니다.
**구성 요소 테스트** – 다양한 구성 요소와 결과 간에 전달되는 메시지를 테스트합니다. 이 테스트의 주요 목표는 구성 요소 테스트에서 멱등성이 될 수 있습니다. 테스트에는 매우 큰 데이터 볼륨 또는 에지 상황 및 비정상적인 입력이 포함될 수 있습니다.
**시스템 테스트** – 시스템을 종단 간 테스트하고 소프트웨어가 비즈니스 요구 사항을 충족하는지 확인합니다. 여기에는 UI(사용자 인터페이스), API, 백엔드 로직 및 최종 상태의 테스트가 포함될 수 있습니다.
**성능 테스트 –** 특정 워크로드에서 수행되는 시스템의 응답성 및 안정성을 결정합니다. 성능 테스트는 확장성, 안정성 및 리소스 사용량과 같은 시스템의 다른 품질 속성을 조사, 측정, 검증 또는 확인하는 데에도 사용됩니다. 성능 테스트 유형에는 부하 테스트, 스트레스 테스트 및 스파이크 테스트가 포함될 수 있습니다. 성능 테스트는 사전 정의된 기준에 대한 벤치마킹에 사용됩니다.
**규정 준수 테스트 –** 코드 변경이 비작동 사양 및/또는 규정의 요구 사항을 준수하는지 확인합니다. 정의된 표준을 구현하고 충족하는지 여부를 결정합니다.
**사용자 승인 테스트 –** 종단 간 비즈니스 흐름을 검사합니다. 이 테스트는 스테이징 환경에서 최종 사용자가 실행하며 시스템이 요구 사항 사양의 요구 사항을 충족하는지 확인합니다. 일반적으로 고객은 이 단계에서 알파 및 베타 테스트 방법을 사용합니다.
## 프로덕션
마지막으로 이전 테스트를 통과한 후 프로덕션 환경에서 스테이징 단계가 반복됩니다. 이 단계에서는 전체 프로덕션 환경에 코드를 배포하기전에 서버의 작은 하위 집합이나 한 서버 또는 AWS 리전에만 새 코드를 배포하여 최종 *카나리 테스트*를 완료할 수 있습니다. 프로덕션에 안전하게 배포하는 방법에 대한 자세한 내용은 [배포 방법](deployment-methods.md) 단원에서 다룹니다.
다음 단원에서는 이러한 단계와 테스트를 통합하기 위한 파이프라인 구축에 대해 설명합니다.
## 파이프라인 구축
이 단원에서는 파이프라인 구축에 대해 설명합니다. 먼저 CI에 필요한 구성 요소만으로 파이프라인을 설정한 다음 나중에 더 많은 구성 요소와 단계가 있는 지속적인 전달 파이프라인으로 전환합니다. 이 단원에서는 대규모 프로젝트에 대한 AWS Lambda 기능 및 수동 승인 사용, 여러 팀, 분기 및 AWS 리전에 대한 계획을 고려하는 방법에 대해서도 설명합니다.
# 지속적 통합을 위한 최소한의 실행 가능한 파이프라인부터 시작
지속적 전달을 위한 조직의 여정은 최소한의 실행 가능한 파이프라인(MVP)에서 시작됩니다. [지속적 통합 및 지속적 전달 구현](implementing-continuous-integration-and-continuous-delivery.md)에서 설명한 것처럼 팀은 코드 스타일 검사를 수행하는 파이프라인이나 배포 없이 단일 단위 테스트를 수행하는 파이프라인 구현과 같은 매우 간단한 프로세스로 시작할 수 있습니다.
핵심 구성 요소는 지속적 전달 오케스트레이션 도구입니다. 이 파이프라인을 구축할 수 있도록 Amazon은 [AWS CodeStar](https://aws.amazon.com/codestar)를 개발했습니다.
![\[alt text not found\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/aws-codestar-setup.png)
* AWS CodeStar 설정 페이지 *
AWS CodeStar는 통합 설정 프로세스, 도구, 템플릿 및 대시보드와 함께 AWS CodePipeline, AWS CodeBuild, AWS CodeCommit 및 AWS CodeDeploy을(를) 사용합니다. AWS CodeStar는 AWS에서 애플리케이션을 신속하게 개발, 빌드 및 배포하는 데 필요한 모든 것을 제공합니다. 이렇게 하면 코드 릴리스를 더 빨리 시작할 수 있습니다. 이미 AWS Management Console에 익숙하고 더 높은 수준의 제어를 원하는 고객은 선택한 개발자 도구를 수동으로 구성하고 필요에 따라 개별 AWS 서비스를 프로비저닝할 수 있습니다.
![\[alt text not found\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/codestar-dashboard.png)
* AWS CodeStar 대시보드 *
AWS CodePipeline은(는) 빠르고 안정적인 애플리케이션 및 인프라 업데이트를 위해 AWS CodeStar 또는 AWS Management Console을(를) 통해 사용할 수 있는 CI/CD 서비스입니다. AWS CodePipeline은(는) 사용자가 정의한 릴리스 프로세스 모델을 기반으로 코드가 변경될 때마다 코드를 빌드, 테스트 및 배포합니다. 이를 통해 기능과 업데이트를 안정적으로 신속하게 제공할 수 있습니다. GitHub 등 인기 있는 서드 파티 서비스를 위한 사전 제작 플러그 인을 사용하거나 사용자 지정 플러그 인을 릴리스 프로세스 단계에 통합함으로써 종단 간 솔루션을 손쉽게 구축할 수 있습니다. AWS CodePipeline은(는) 사용한 만큼만 비용을 지불하면 됩니다. 선수금이나 장기 약정을 적용하지 않습니다.
AWS CodeStar 및 AWS CodePipeline의 단계는[ 소스, 빌드, 스테이징 및 프로덕션 CI/CD 단계](testing-stages-in-continuous-integration-and-continuous-delivery.md)에 직접 매핑합니다. 지속적인 전달이 바람직하지만, 소스 리포지토리를 확인하고 빌드 작업을 수행하는 간단한 2단계 파이프라인부터 시작할 수 있습니다.
![\[alt text not found\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/codepipeline-source-build.png)
* AWS CodePipeline - 소스 및 빌드 단계 *
AWS CodePipeline의 경우 소스 단계에서는 GitHub, AWS CodeCommit 및 Amazon Simple Storage Service(Amazon S3)의 입력을 받을 수 있습니다. 빌드 프로세스의 자동화는 지속적인 전달을 구현하고 지속적인 배포로 이동하기 위한 중요한 첫 단계입니다. 빌드 아티팩트를 생성할 때 사람이 개입하지 않으면 팀의 부담이 줄어들고 수동 패키징으로 인한 오류가 최소화되며 소모성 아티팩트를 더 자주 패키징할 수 있습니다.
AWS CodePipeline은(는) 완전 관리형 빌드 서비스인 AWS CodeBuild과(와) 원활하게 작동하므로 파이프라인 내에서 코드를 패키징하고 단위 테스트를 실행하는 빌드 단계를 더 쉽게 설정할 수 있습니다. AWS CodeBuild을(를) 사용하면 자체 빌드 서버를 프로비저닝, 관리 또는 확장할 필요가 없습니다. AWS CodeBuild은(는) 지속적으로 확장되고 여러 빌드를 동시에 처리하므로 빌드가 대기열에서 대기하지 않습니다. 또한 AWS CodePipeline은(는) Jenkins, Solano CI 및 TeamCity와 같은 빌드 서버와 통합됩니다.
예를 들어 다음 빌드 단계에서는 세 가지 작업(단위 테스트, 코드 스타일 확인 및 코드 메트릭 수집)이 병렬로 실행됩니다. AWS CodeBuild을(를) 사용하면 부하를 처리하기 위해 빌드 서버를 구축하거나 설치할 필요 없이 이러한 단계를 새 프로젝트로 추가할 수 있습니다.
![\[alt text not found\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/codepipeline-build-functionality.png)
* AWS CodePipeline - 빌드 기능 *
그림(*AWS CodePipeline - 소스 및 빌드 단계*)에 표시된 소스 및 빌드 단계는 지원 프로세스 및 자동화와 함께 팀이 지속적인 통합으로 전환하는 데 도움이 됩니다. 이러한 완성도 수준에서 개발자는 주기적으로 빌드 및 테스트 결과에 주의를 기울여야 합니다. 또한 상태가 양호한 단위 테스트 기반을 개발하고 유지해야 합니다. 그 결과 CI/CD 파이프라인에 대한 팀 전체의 신뢰가 강화되고 채택을 가속화합니다.
![\[alt text not found\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/codepipeline-stages.png)
* AWS CodePipeline 단계 *
# 지속적 전달 파이프라인
지속적 통합 파이프라인이 구현되고 지원 프로세스가 구축되면 팀은 지속적 전달 파이프라인으로 전환할 수 있습니다. 이러한 전환을 위해서는 팀이 애플리케이션 구축과 배포를 모두 자동화해야 합니다.
지속적 전달 파이프라인의 특징은 수동 승인 후 프로덕션 단계를 수행하는 스테이징 및 프로덕션 단계가 있다는 것입니다.
지속적 통합 파이프라인을 구축한 것과 같은 방식으로 팀은 배포 스크립트를 작성하여 점진적으로 지속적 전달 파이프라인을 구축할 수 있습니다.
애플리케이션의 필요에 따라 일부 배포 단계를 기존AWS 서비스로 추상화할 수 있습니다. 예를 들어 AWS CodePipeline은(는) Amazon EC2 인스턴스 및 온프레미스에서 실행 중인 인스턴스에 대한 코드 배포를 자동화하는 서비스인 AWS CodeDeploy, Chef를 사용하여 애플리케이션을 운영하는 데 도움이 되는 구성 관리 서비스인 AWS OpsWorks, 웹 애플리케이션 및 서비스를 배포 및 확장하는 서비스인 AWS Elastic Beanstalk에 직접 통합됩니다.
AWS에는 인프라 및 파이프라인에 AWS CodeDeploy을(를) 구현하고 통합하는 방법에 대한 자세한 [설명서](https://docs.aws.amazon.com/codepipeline/latest/userguide/getting-started-w.html#getting-started-w-create-deployment)가 있습니다.
팀이 애플리케이션 배포를 자동화한 후 다양한 테스트를 통해 배포 단계를 확장할 수 있습니다. 예를 들어 다음 그림처럼 Ghost Inspector, Runscope 등과 같은 서비스와의 다른 기본 통합을 추가할 수 있습니다.
![\[alt text not found\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/codepipeline-code-test-deployment.png)
* AWS CodePipeline- 배포 단계의 코드 테스트 *
# Lambda 작업 추가
AWS CodeStar 및 AWS CodePipeline은(는) [AWS Lambda과(와)의 통합](https://docs.aws.amazon.com/codepipeline/latest/userguide/how-to-lambda-integration.html)을 지원합니다. 이러한 통합을 통해 사용자 환경에서 사용자 지정 리소스 생성, 서드 파티 시스템(예: Slack)과의 통합, 새로 배포된 환경에 대한 확인 수행 등 광범위한 작업을 구현할 수 있습니다.
CI/CD 파이프라인에서 Lambda 함수를 사용하여 다음 작업을 수행할 수 있습니다.
+ AWS CloudFormation 템플릿을 적용하거나 업데이트하여 사용자 환경에 대한 변경 사항을 롤아웃합니다.
+ AWS CloudFormation을(를) 사용하여 파이프라인의 한 단계에서 리소스를 주문형으로 생성하고 다른 단계에서 삭제합니다.
+ [표준 이름 레코드](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html)(CNAME) 값을 교체하는 Lambda 함수를 사용하여 AWS Elastic Beanstalk에 가동 중지 시간 없이 애플리케이션 버전을 배포합니다.
+ Amazon Elastic Container Service(ECS) Docker 인스턴스에 배포합니다.
+ AMI 스냅샷을 생성하여 빌드하거나 배포하기 전에 리소스를 백업합니다.
+ IRC(인터넷 중계 채팅) 클라이언트에 메시지를 게시하는 등 서드 파티 제품과의 통합을 파이프라인에 추가합니다.
# 수동 승인
필수 AWS Identity and Access Management(IAM) 권한이 있는 다른 사용자가 작업을 승인하거나 거부할 수 있도록 파이프라인 처리를 중지할 지점의 파이프라인 단계에 승인 작업을 추가할 수 있습니다.
작업이 승인되면 파이프라인 처리가 재개됩니다. 작업이 거부되거나 파이프라인이 작업에 도달하여 중지된 지 7일 이내에 아무도 작업을 승인하거나 거부하지 않는 경우, 작업이 실패한 것과 같으며 파이프라인 처리가 계속되지 않습니다.
![\[alt text not found\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/codedeploy-manual-approvals.png)
* AWS CodeDeploy- 수동 승인 *
# CI/CD 파이프라인에 인프라 코드 변경 배포
AWS CodePipeline은(는) 파이프라인의 모든 단계에서 배포 작업으로 AWS CloudFormation을(를) 선택할 수 있습니다. 그런 다음 스택 생성 또는 삭제, [변경 세트](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-whatis-concepts.html#d0e3952) 생성 또는 실행 등 AWS CloudFormation에서 수행할 특정 작업을 선택할 수 있습니다. [스택](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-whatis-concepts.html#d0e3929)은 AWS CloudFormation 개념이며 관련 AWS 리소스 그룹을 나타냅니다. 코드형 인프라를 프로비저닝하는 방법에는 여러 가지가 있지만, AWS CloudFormation은(는) 가장 포괄적인 AWS 리소스 세트를 코드로 설명할 수 있는 확장 가능하고 완전한 솔루션으로 AWS에서 권장하는 포괄적인 도구입니다. AWS에서는 AWS CodePipeline 프로젝트의 AWS CloudFormation을(를) 사용하여 [인프라 변경 및 테스트를 추적](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/continuous-delivery-codepipeline.html)할 것을 권장합니다.
# 서버리스 애플리케이션용 CI/CD
AWS CodeStar, AWS CodePipeline, AWS CodeBuild 및AWS CloudFormation을(를) 사용하여 서버리스 애플리케이션용 CI/CD 파이프라인을 구축할 수도 있습니다. 서버리스 애플리케이션은 [Amazon Cognito](https://aws.amazon.com/cognito), Amazon S3, Amazon DynamoDB 및 AWS Lambda과(와) 같은 관리형 서비스를 이벤트 기반 서비스와 통합하고 서버 관리가 필요하지 않은 방식으로 애플리케이션을 배포합니다. 서버리스 애플리케이션 개발자인 경우 AWS CodePipeline, AWS CodeBuild 및 AWS CloudFormation을(를) 조합하여 AWS Serverless Application Model로 구축된 템플릿에 표현되는 서버리스 애플리케이션의 구축, 테스트 및 배포를 자동화할 수 있습니다. 자세한 내용은 [Lambda 기반 애플리케이션의 배포 자동화](https://docs.aws.amazon.com/lambda/latest/dg/automating-deployment.html)의 AWS Lambda 설명서를 참조하십시오.
AWS Serverless Application Model Pipelines(AWS SAM 파이프라인)를 사용하여 조직의 모범 사례를 따르는 안전한 CI/CD 파이프라인을 생성할 수도 있습니다. AWS SAM Pipelines는 몇 분 내에 배포 빈도 가속화, 변경을 위한 리드 타임 단축 및 배포 오류 감소와 같은 CI/CD의 이점에 대한 액세스를 제공하는 새로운 AWS SAM CLI 기능입니다. AWS SAM Pipelines에는 AWS 배포 모범 사례를 따르는 AWS CodeBuild/CodePipeline용 기본 파이프라인 템플릿 집합이 함께 제공됩니다. 자세한 내용과 자습서를 보려면 [AWS SAM Pipelines 소개](https://aws.amazon.com/blogs/compute/introducing-aws-sam-pipelines-automatically-generate-deployment-pipelines-for-serverless-applications/) 블로그를 참조하십시오.
# 여러 팀, 분기 및 AWS 리전을 위한 파이프라인
대규모 프로젝트의 경우 여러 프로젝트 팀이 서로 다른 구성 요소에서 작업하는 경우가 일반적입니다. 여러 팀이 단일 코드 리포지토리를 사용하는 경우, 각 팀이 자체 분기를 갖도록 매핑할 수 있습니다. 또한 프로젝트의 최종 병합을 위한 통합 또는 릴리스 분기가 있어야 합니다. 서비스 지향 또는 마이크로 서비스 아키텍처를 사용하는 경우, 각 팀은 자체 코드 리포지토리를 보유할 수 있습니다.
첫 번째 시나리오에서는 단일 파이프라인을 사용하는 경우 파이프라인을 차단하여 한 팀이 다른 팀의 진행 상황에 영향을 미칠 수 있습니다. AWS는 팀 분기에 대한 특정 파이프라인과 최종 제품 제공을 위한 또 다른 릴리스 파이프라인을 생성할 것을 권장합니다.
# AWS CodeBuild과(와) 파이프라인 통합
AWS CodeBuild은(는) 조직에서 거의 무제한으로 고가용성 빌드 프로세스를 구축할 수 있도록 설계되었습니다. AWS CodeBuild에서는 널리 사용되는 여러 언어에 대한 빠른 시작 환경과 사용자가 지정한 Docker 컨테이너를 실행할 수 있는 기능을 제공합니다.
Git 및 CodePipeline Lambda 작업 외에도 AWS CodeCommit, AWS CodePipeline 및 AWS CodeDeploy과(와)의 긴밀하게 통합되는 이점을 갖춘CodeBuild 도구는 매우 유연합니다.
빌드 전/후 작업을 포함하여 각 빌드 단계를 식별하는 `buildspec.yml` 파일을 포함하거나 CodeBuild 도구로 지정된 작업을 통해 소프트웨어를 빌드할 수 있습니다.
CodeBuild 대시보드를 사용하여 각 빌드의 자세한 기록을 볼 수 있습니다. 이벤트는 Amazon CloudWatch Logs 로그 파일로 저장됩니다.
![\[alt text not found\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/cloudwatch-logs-log-files.png)
* AWS CodeBuild의 CloudWatch Logs 로그 파일 *
# Jenkins와 파이프라인 통합
Jenkins 빌드 도구를 사용하여 [제공 파이프라인을 생성](https://www.jenkins.io/doc/book/pipeline/getting-started/)할 수 있습니다. 이 파이프라인은 지속적 전달 단계를 구현하기 위한 단계를 정의하는 표준 작업을 사용합니다. 그러나 Jenkins가 다시 시작될 때 파이프라인의 현재 상태가 유지되지 않고 수동 승인을 구현하는 것이 간단하지 않으며 복잡한 파이프라인의 상태를 추적하는 것이 복잡할 수 있기 때문에 이러한 접근 방식은 대규모 프로젝트에 적합하지 않을 수 있습니다.
대신 AWS에서는 [AWS Code Pipeline Plugin](https://wiki.jenkins-ci.org/display/JENKINS/AWS+CodePipeline+Plugin)을 사용하여 Jenkins로 지속적인 전달을 구현하는 것이 좋습니다. 이 플러그 인을 사용하면 Groovy와 유사한 도메인 별 언어를 사용하여 복잡한 워크 플로를 설명할 수 있으며 복잡한 파이프라인을 오케스트레이션하는 데 사용할 수 있습니다. AWS Code Pipeline Plugin의 기능은 파이프라인에 정의된 단계의 현재 진행 상황을 시각화하는 [Pipeline Stage View Plugin](https://plugins.jenkins.io/aws-codepipeline/) 또는 서로 다른 분기에서 빌드를 그룹화하는 [Pipeline Multibranch Plugin](https://plugins.jenkins.io/workflow-multibranch/)과 같은 위성 플러그 인을 사용하여 향상할 수 있습니다.
AWS에서는 파이프라인 구성을 *Jenkinsfile*에 저장하고 소스 코드 리포지토리에 체크인할 것을 권장합니다. 이를 통해 파이프라인 코드의 변경 사항을 추적할 수 있으며 Pipeline Multibranch Plugin으로 작업할 때 더욱 중요해집니다. 또한 AWS에서는 파이프라인을 여러 단계로 나누는 것이 좋습니다. 이렇게 하면 파이프라인 단계를 논리적으로 그룹화하고 Pipeline Stage View Plugin이 파이프라인의 현재 상태를 시각화할 수 있습니다.
다음 그림은 Pipeline Stage View Plugin으로 시각화된 네 가지 정의된 단계가 있는 샘플 Jenkins 파이프라인을 보여줍니다.
![\[alt text not found\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/defined-stages-of-jenkins.png)
*Pipeline Stage View Plugin으로 시각화된 Jenkins 파이프라인의 정의된 단계*