소프트웨어 엔지니어링에서 파이프라인(Pipeline)은 무엇인가? Deployment, CI & CD 파이프라인에 대한 소개

이 글은 bmc blogs 의 “What is a Pipeline in Software Engineering? Intro to Deployment, CI, & CD Pipelines” 을 번역한 것 입니다. 원작자의 허락없이 재개시 및 상업적 이용은 불가합니다.

https://www.bmc.com/blogs/deployment-pipeline/

소프트웨어 엔지니어링 팀에서 파이프라인(pipeline)은 개발자나 DevOps 전문가가 효율적이면서도 확실하게 그들의 코드를 컴파일(Compile), 빌드(Build) 그리고 그들의 프로덕션 컴퓨팅 플랫폼에 배포(Deploy) 하게 해주는 자동화된 프로세스들의 묶음(set) 이다. 파이프라인이 이래야 한다거나 반드시 활용해야할 도구(Tools)를 지정하는 강하고 빠른 규칙은 없지만, 파이프라인이 가져야할 가장 일반적인 컴포넌트들이 있다. 빌드 자동화(build automation)/지속적 통합(continuous integration), 테스트 자동화(test automation), 그리고 배포 자동화(deployment automation) 이다.

일반적으로 파이프라인은 다음의 카테고리로 구분되는 일련의 도구들로 구성된다.

  • Source Control
  • Build tools
  • Containerisation
  • Configuration Management
  • Monitoring

소프트웨어 배송 파이프라인(Software Delivery Pipeline) 개념의 핵심은 어떤 파이프라인의 단계 사이에 수동적 단계나 수동적인 변경이 필요없는 자동화(automation) 이다. 휴먼에러(Human error)는 이러한 지루하고 반복적인 작업을(역, 파이프라인의 단계들을 말한다) 수동으로 하게되면 발생할 수 있고 결국 잘못된 배포로 인해 올바른 산출물 생성에 영향을 미치고 잠재적으로 SLA 까지 영향을 준다.

Deployment Pipeline

배포 파이프라인은 자동화된 방식으로 버전 컨트롤(Version control) 로부터 코드를 가지고 오고 당신의 애플리케이션 사용자에게 손쉽게 활용할 수 있도록 만들어주는 프로세스이다. 개발팀이 프로젝트나 기능에 대해 일을 할때에 그들의 일을 빌드, 테스트, 배포를 위한 확실하고 효율적인 방법이 필요하다. 역사적으로, 이것은 많은 커뮤니케이션과 많은 휴먼 에러를 발생시키는 수동 프로세스들이였다.

전통적인 배포 파이프라인 단계는 다음과 같다.

Version Control

일반적으로 코드를 가지고 일을하는 소프트웨어 개발자들은 코드 변경사항을 소스 컨트롤에(e.g. github) 커밋 한다. 소스 컨트롤에 커밋하면 코드 컴파일화, 유니테스트, 코드 분석 그리고 인스톨러 생성을 트리거하는 배포 파이프라인의 첫번째 단계가 시작된다. 이런 모든 과정이 성공적으로 완료되면 실행결과물은 바이너리로 만들어지고 나중에 사용위해 아티팩트 저장소에 저장 된다.

Acceptance Tests

합격 테스팅은 비지니스에 의해서 미리 정의된 합격 기준에 부합하는 테스트를 위해 미리 컴파일/빌드된 코드에 대해 테스트 묶음을 실행하는 프로세스이다.

Independent Deployment

독립 배포는 컴파일되고 테스트된 아티팩트를 개발환경에 배포하는 프로세스다. 개발 환경은 이상적으로 프로덕트 환경의 판박이 복사본이여 하거나 최소한 아주 비슷해야 한다. 이것은 기능적으로 모든 추가적인 자동화되거나 수동 테스팅을 위한 인프라 준비와 같은 프로덕션에 대해 테스트되어질 수 있는 소프트웨어 이다.

Production Deployment

이 프로세스는 일반적으로 운영팀(Operations) 이나 데브옵스팀에 의해서 다루어진다. 이것은 독립 패포 프로세스와 매우 유사해야 하며 라이브 프로덕션 서버에 코드를 배포해야 한다. 전통적으로 이 프로세스는 예기치못한 이벤트 이슈에 쉽게 버전 롤백을 하거나 제로 다운타임 배포를 위해서 Blue/Green 배포 혹은 Canary 릴리즈를 포함 한다. 제로 다운 타임이 아닌 상황에서 배포 기능 릴리즈 윈도우는 일반적으로 비지니스와 협상을 했었다.

Continuous Integration and Continuous Delivery Pipelines

Continuous Integration (CI) 는 개발자들이 하루에 여러번 그들의 코드를 버전 제어 저장소에 체크하는 방법이다. 이러한 체크는 오류를 빠르고 쉽게 찾을 수 있게 해주며, 자동화된 빌드 파이프라인은 이러한 체크인으로부터 트리거 된다.

CI 의 장점은 다음과 같다.

  • 크기가 좀 더 작은 변경은 좀 더 큰 코드 베이스로 통합하기가 좀 더 쉽다.
  • 당신이 무슨 일을 하고 있는지를 다른 팀 멤버에게 보여주기가 좀 더 쉽다.
  • 좀 더 큰 작업 부분에 버그를 좀 더 적은 디버깅 작업으로 문제을 해결하기 아주 쉽도록 조기에 발견하게 한다.
  • 일관된 코드 컴파일/빌드 테스팅
  • 거의 없는 통합 이슈는 빠른 배포를 가능하게 한다.

Continuous Delivery (CD) 는 개발자와 운영엔지니어가 버그 수정, 기능 및 구성 변경 사항을 프로덕트에 안정적으로 신속하고 지속적으로 배포할 수 있도록 해주는 프로세스다. 지속적 배포는(Continuous Delivery) 필요시 자신있게 수행 할 수 있도록 반복적으로 수행되는 코드 배포 파이프라인의 이점을 제공한다.

CD의 이점은 다음과 같다.

  • 아주 낮은 리스크 릴리즈 – Blue/Green 배포와 카나리 릴리즈는 사용자가 신경쓰지 않아도 되는 제로 다운타임 배포를 보장하며 이전 릴리즈로 롤백하는데 상대적으로 어려움이 없다.
  • 빠른 버그 픽스 & 기능 배포 – 기능 또는 버그 수정을 완료하고 승인 및 통합 테스트를 통과한 경우 CI & CD 사용 – CD 파이프라인은 이것들을 재빨리 프로덕트에 배포한다.
  • 비용 절약 – 지속적인 배포를 통해 팀은 기능 및 버그 픽스를 작업 배치로 처리할 수 있으므로 사용자 피드백을 훨씬 빨리 받을 수 있다. This allows for changes to be made along the way thus reducing the overall time and cost of a project

Blue/Green Deployments

Blue/Green 배포 프로세스의 활용은 하나는 Blue, 다른 하나는 Green 으로 이름붙여진 프로덕트 환경 미러 복사본을 생성함으로써 리스크와 다운타임을 줄인다. 오직 하나의 환경만이 매시간 라이브 프로덕트 트래픽을 제공하도록 살아 있다. 배포 소프트웨어가 non-live 환경에 배포되는 중에는 – 이것은 라이브 프로덕트 트래픽이 배포되는 동안 영향을 받지 않는다는 것을 의미한다. 테스트는 현재 라이브 환경이 아닌 곳에서 실행되며, 모든 테스트가 사전에 정의된 기준을 충족하면 트래픽 라우팅이 라이브 환경이 되도록 라이브 환경이 아닌 환경으로 교체한다. 이 과정은 기존 라이브 환경이 현재 라이브 환경이 아닌것으로 되면서 다음번 배포에 반복된다.

Canary Deployments

Blue/Green 배포와는 달리, Canary 배포는 병렬로 운영되어지는 중복 환경에 의존하지 않는다. Canary 배포는 모든 사용자/서버들에 지속적으로 릴리즈를 롤 아웃(Roll out) 하기 전에 라이브 프로덕션 테스트를 위해 사용자/서버들의 백분율이나 특정 버전으로 릴리즈를 롤라웃 한다. Canary 릴리즈의 주요한 장점은 일찍 실패를 탐지할 수 있다는 것과 예외나 실퍠 이벤트 발생시에 영향을 받는 사용자/서버들의 수가 제한됨에 따라 일부 변경된 것만 롤백할 수 있다는 것이다.

요약을하면, CI 는 소프트웨어 개발팀이 그들의 코드를 체크인하고 품질을 확인하고 컴파일할 수 있도록 하는 자동화된 프로세스다. CD 는 개발과 운영 팀이 자동화된 방식으로 그들의 최종 기능에 새로운 기능과 버그 픽스를 안정적이고 효율적으로 배포할 수 있도록 해준다.

아래에 몇가지 CI/CD 파이프라인 빌드를 위해 사용할 수 있는 다양한 도구들이 있으며, 모두 무료로 시작할 수 있는 이점과함께 안정적이고 강력한 CI/CD 파이프라인을 빌드하는데 사용되어질 수 있다.

Post a comment

You may use the following HTML:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">