AWS CodePipeline

CodePipeline

 

- 소프트웨어를 프로덕션으로 빌드, 테스트, 배포하는 과정을 자동화하는 지속적인 제공 서비스

• 지속적 통합 (CI : Continuous Integration) : 자동화된 빌드 및 테스트가 수행된 후 개발자가 코드 변경 사항을 중앙 레포지토리에 정기적으로 병합하는 데브옵스 소프트웨어 개발 방식으로 소프트웨어 릴리스 프로세스 중 빌드 또는 통합 단계를 주로 가리키며 자동화 구성요소와 문화적 구성요소 모두를 포함

• 지속적 전달 (CD : Continuous Delivery) : 프로덕션에 릴리스하기 위한 코드 변경이 자동으로 준비되는 소프트웨어 개발 방식으로 빌드 단계 이후의 모든 코드 변경을 테스트 환경 또는 프로덕션 환경에 배포함으로써 지속적 통합을 확장

 

 

 

 

 

CodePipeline 릴리스 프로세스

 

 

 

 

1. 개발자가 소스 레포지토리에 수정을 하면 CodePipeline이 자동으로 수정 내용을 감지

 

2. 수정 내용을 빌드하고 테스트를 구성하는 경우에는 테스트를 실행

 

3. 테스트가 종료되면 빌드된 코드를 스테이징 서버로 배포

 

4. 스테이징 서버에서 통합이나 로드 테스트 같은 추가 테스트를 실행

 

5. 테스트가 성공적으로 끝나고 파이프라인에 추가된 수동 승인 작업에 승인을 받고나면 테스트가 완료된 코드를 프로덕션 인스턴스에 배포

 

 

 

아키텍처

 

 

 

 

 

- 릴리스 프로세스의 워크플로우 생성 및 관리를 지원

 

- 소프트웨어 변경 사항이 릴리스 프로세스에 적용되는 방법을 설명하는 워크플로우 (일련의 작업 과정) 구성

 

 

수정

 

- 수정이란 GitHub Repo 또는 CodeCommit Repo에 Push된 Commit, S3 Bucket에서 파일 업데이트처럼 소스에 변경을 가하여 CodePipeline에 대한 소스작업을 구성한 것

 

- 각 버전은 파이프라인을 거쳐 개별적으로 실행

 

- 동일한 파이프라인에서 여러가지 수정을 처리할 수 있지만 각 단계에서는 한번에 한개의 수정만 처리할 수 있음

 

- 소스 단계에서 지정한 위치에 변경을 처리하면 파이프라인을 통해 수정이 실행 

(파이프라인에 여러 개의 소스 작업이 포함되어 있는 경우 소스 작업 한개에만 변경이 감지되더라도 모든 소스작업이 다시 실행)

 

 

워크플로우

 

- 파이프라인은 워크플로우를 여러 단계로 나눔 (각 단계는 스테이지로도 표현)

• 빌드 단계에서는 코드를 빌드하고 테스트를 실행

• 배포 단계에서는 코드 업데이트를 환경에 배포

• 추적과 제어, 보고 성능을 높이기 위해 릴리스 프로세스의 각 단계에 이름을 붙일 수 있음 (소스, 빌드, 스테이징)

 

- 각 단계(Stage)에는 고유한 이름 (소스, 빌드, 스테이징)이 붙으며 워크플로우의 일환으로 일련의 작업(Action)이 포함

 

- 하나의 단계에서는 한개의 수정만 처리할 수 있는데 해당 수정이 실행되고 성공적으로 끝나야 단계가 완료된 것으로 간주 되어 다음 단계로 전환

(단계가 끝난 후 파이프 라인은 그 단계에서 작업으로 생성된 아티팩트[빌드의 결과로 얻을 수 있는 실행파일을 의미 (작업 결과물)]와 수정 내용을 다음 단게로 전환)

 

- 다음 단계로 전환은 수동으로 활성화하거나 비활성화 할 수 있음

 

- 모든 단계에는 최소 한개 이상의 작업이 포함되는데 이것은 아티팩트에서 수행하는 일종의 작업임

 

- 파이프 라인 작업은 단계 구성에서 정의한 대로 지정된 순서나 연속 또는 병렬로 발생

(배포 단계에서는 한개 이상의 스테이징 서버에 코드를 배포하는 배포작업이 포함, 필요에 따라 단일 시작 작업으로 단계를 구성하고 해당 단계에 작업을 추가 가능)

 

- 수정이 파이프 라인을 통해 실행되기 시작하면 CodePipeline은 해당 단계와 작업을 파이프라인에서 S3 버킷에 작업할 파일이나 변경 내용을 복사

(이런 객체를 아티팩트라 하며 작업 소스(입력 아티팩트) 또는 작업의 출력(출력아티팩드)라고 함, 아티팩트는 한 가지 이상의 작업에 의해 작동)

 

 

작업

 

 

 

- 위의 그림은 파이프라인에서 입력 아티팩트와 출력 아티팩트를 생성하고 소비하는 방법

 

- 작업의 유형

• 작업을 실행하는 동안 소비하거나 작업하는 입력 아티팩트

• 작업의 출력인 출력 아티팩트

 

- 파이프라인의 모든 출력 아티팩트에는 고유의 이름이 있어야함

 

- 하나의 작업에 대한 모든 입력 아티팩트는 앞선 파이프 라인 내의 작업의 출력 아티팩트와 일치해야함

(한 단계 전이든 몇단계 전에 실행된 작업이든 중요하지 않음)

 

 

전환

 

- 전환이란 워크플로우의 한 단계에서 다음 단계로 지속하는 파이프 라인 내 수정 행동

( 콘솔에서는 어떤 단계에가 일어나는지 순서를 보여주기 위해 전환 화살표가 여러 단계를 함께 연결)

 

- 단계가 끝나면 기본값으로 수정 내용이 파이프라인의 다음 단계로 전환 (다음 단계로 전환 비활성화 가능, 활성화를 다시 시작하면 중지된 부분부터 전환 실행)

 

- 한 단계를 통해 한번에 하나의 리비전만 실행할 수 있기 때문에 다음 단계를 이용할 수 있을때까지 이전 단계에서 완료한 모든 리비전을 CodePipeline이 일괄 처리

(최근 리비전이 단계를 거치고 나면 배치를 동해 최근 리비전으로 교체)

 

- 승인 작업은 권한이 허용될 때가지 파이프라인이 다음 작업으로 전환하지 않도록 방지 (승인받은 IAM 사용자만 가능)

 

- 승인 작업은 코드 컴토를 마친 후 다음 파이프라인으로 전환하고 싶을때, 파이프라인이 최종 프로덕션 단계로 전활할 시기를 제어하고 싶을때 사용

(프로덕션 배포 직전에 중지 후 공지를 거친 다음 실행 가능)

 

- 실패는 한 단계에서 성공적으로 완료하지 못한 작업 (다음 단계로 전환하지 못함)으로 다음 중 하나가 발생할때까지 CodePipe이 파이프라인을 중단

• 실패한 작업이 포함된 단계를 수동으로 재시작

• 해당 수정에 대하여 파이프라인 재시작

• 소스 단계에서 다른 수정 실행

 

- 소스 위치에 변경을 가하거나 수동으로 파이프 라인을 시작할 때 파이프라인이 자동으로 시작

(지정된 이벤트가 발생하면 파이프 라인을 자동으로 시작하도록 CloudWatch의 규칙 설정 가능[ CodeCommit 소스 레포지토리가 있는 파이프라인을 만들거나 편집하면 CodePipeline이 CloudWatch Events를 사용하여 레포지토리 변경을 감지하고 변경이 발생하면 파이프라인 시작])

 

---

 

CodePipeline 과정 

 

 

 

1. CodeCommit에 코드가 커밋되면 CodePipeline에서 코드가 커밋된것을 인식하여 자동으로 CodeBuild 과정을 진행 (Commit -> Build 과정 활성화 체크)

 

2. CodeBuild 과정에서는 정의된 명세서 (Buildspec) 대로 테스트를 거침

(Build VM 생성 -> CodeBuild Agent가 VM에서 실행 -> Source Code Download -> Buildspec에 정의된 대로 Build 실행 -> Build 결과 출력 및 아티팩트 생성 -> 아티팩트 S3에 업로드 ->  Build VM 삭제)

 

3. CodeBuild 단계에서 출력된 아티팩트를 S3에서 CodeDeploy가 다운로드

 

4. Appspec에 정의된 대로 스테이징 개체 또는 프로덕션 개체 생성

 

5. 배포 과정은 Appspec에 정의된 hooks 대로 블루/그린 방식 또는 인플레이스 방식으로 배포 (IAM으로 배포 인가시, Build 후 자동 Deploy 선택)

 

6. 배포 결과 출력

 

 

참조 URL

 

https://docs.aws.amazon.com/ko_kr/codepipeline/latest/userguide/concepts.html

https://blog.leedoing.com/82

https://www.holaxprogramming.com/2017/10/16/devops-aws-codestar/