'CI/CD란?' 알기 쉽게 설명한 지속적 통합과 지속적 전달

견고한 CI/CD 파이프라인을 갖춘 성숙한 데브옵스팀은 지속적 배포도 구현할 수 있다. 지속적 배포에서는 애플리케이션 변경이 CI/CD 파이프라인을 거쳐 실행되고 통과한 빌드는 프로덕션 환경에 바로 배포된다. 지속적 배포가 모든 비즈니스 애플리케이션에서 최적의 방법은 아니지만, 지속적 배포를 실천하는 팀 중에서는 매일, 심지어 매시간 프로덕션으로 배포하는 팀도 있다. 

지속적 통합은 어떻게 동작하는가

지속적 통합은 프로세스 역학과 자동화를 기반으로 하는 개발 철학이다. 지속적 통합을 실천하는 개발자는 버전 제어 리포지토리에 자주 코드를 커밋한다. 대부분 팀은 최소 일일 단위의 코드 커밋 표준을 둔다. 그 이유는 장기간에 걸쳐 개발된 큰 코드보다 작은 규모로 작게 변화된 코드에서 결함과 기타 소프트웨어 품질 문제를 파악하기가 더 쉽다는 데 있다. 또한 개발자가 짧은 커밋 주기에 따라 작업하면 여러 개발자가 동일한 코드를 편집하고 커밋할 때 병합해야 하는 상황이 발생할 가능성도 낮출 수 있다. 

지속적 통합을 구현하는 팀은 버전 제어 구성과 실행 정의부터 시작하는 경우가 많다. 코드 체크인은 빈번하게 이뤄지지만 애자일 팀이 기능과 수정을 개발하는 기간은 그보다 더 짧을 수도, 길 수도 있다. 따라서 지속적 통합을 실행하는 개발 팀은 다양한 방법을 사용해 프로덕션에 배포할 준비가 된 기능과 코드를 제어한다. 

많은 팀이 런타임에 기능과 코드를 켜고 끄기 위한 구성 메커니즘인 기능 플래그를 사용한다. 아직 개발 중인 기능은 코드에서 기능 플래그로 래핑되어 주 분기와 함께 프로덕션에 배포되지만, 사용할 준비가 될 때까지 꺼진 상태로 유지된다. 최근 연구에서 기능 플래그를 사용하자 데브옵스팀의 개발 빈도가 9배 증가한 것으로 나타났다. 클라우드비스(CloudBees), 옵티마이즐리 롤아웃(Optimizely Rollouts), 런치다클리(LaunchDarkly)와 같은 기능 플래그 툴은 CI/CD 툴과 통합되어 기능 수준 구성을 지원한다. 
 

자동화된 빌드 

자동화된 빌드 프로세스에서는 모든 소프트웨어, 데이터베이스 및 기타 구성요소가 함께 패키징된다. 예를 들어 자바 애플리케이션을 개발한다면 지속적 통합은 HTML, CSS, 자바스크립트와 같은 모든 정적 웹 서버 파일을 자바 애플리케이션 및 모든 데이터베이스 스크립트와 함께 패키징한다. 

지속적 통합에서 모든 소프트웨어 및 데이터베이스 구성요소를 패키징할 뿐만 아니라 자동화에서 단위 테스트 및 기타 유형의 테스트도 실행한다. 테스트는 개발자에게 코드 변경이 장애를 유발하지 않는지 확인하기 위한 중요한 피드백을 제공한다. 

대부분 CI/CD 툴은 개발자가 필요에 따라 빌드를 실행할 수 있게 해준다. 버전 제어 리포지토리의 코드 커밋에 의해 또는 정해진 일정에 따라 트리거되는 방식이다. 팀은 규모에 가장 잘 맞는 빌드 일정과 일일 예상 커밋 수, 그리고 기타 애플리케이션 고려 사항을 결정해야 한다. 최선의 방법은 커밋과 빌드가 빠른지를 확인하는 것이다. 빠르지 않을 경우 신속한 코딩과 수시 커밋을 실현하는 데 지장이 발생할 수 있다. 
 

지속적 테스트와 보안 자동화 

자동화된 테스트 프레임워크는 품질 보장 엔지니어가 다양한 유형의 테스트를 정의, 실행하고 자동화하는 데 유용하다. 이런 테스트는 개발팀이 소프트웨어 빌드의 통과 또는 실패 여부를 파악할 수 있게 해준다. 여기에는 모든 스프린트의 끝에 개발되고 전체 애플리케이션의 회귀 테스트에 들어가는 기능 테스트도 포함된다. 회귀 테스트는 코드 변경이 테스트 커버리지가 있는 애플리케이션 기능 영역 전반에서 개발된 하나 또는 여러 테스트의 실패를 유발하는지 여부를 팀에 알려준다.  

최선의 방법은 개발자가 로컬 환경에서 회귀 테스트 전체 또는 일부를 실행할 수 있도록 하고, 이를 의무화하는 것이다. 이렇게 하면 개발자는 코드 변경이 회귀 테스트를 통과한 이후에만 버전 제어에 코드를 커밋하게 된다. 

그러나 회귀 테스트는 시작일 뿐이다. 데브옵스팀은 성능, API, 브라우저 및 디바이스 테스트도 자동화한다. 이제 팀은 시프트-레프트(shift-left) 테스트를 위해 CI/CD 파이프라인에 정적 코드 분석과 보안 테스트도 내장할 수 있다. 또한 애자일 팀은 서비스 가상화를 사용하여 서드파티 API, SaaS, 및 기타 자체 제어 범위를 벗어난 시스템과의 상호작용도 테스트할 수 있다. 핵심은 명령줄, 웹훅 또는 웹 서비스를 통해 이러한 테스트를 트리거하고 성공 또는 실패 응답을 받을 수 있다는 것이다. 

지속적 테스트는 CI/CD 파이프라인이 테스트 자동화를 통합한다는 것을 의미한다. 일부 단위 및 기능 테스트는 지속적 통합 프로세스 전에, 또는 도중에 문제에 플래그를 지정한다. 성능 및 보안 테스트와 같이 전체 제공 환경이 필요한 테스트는 지속적 제공 내에 통합되어 빌드가 타겟 환경에 전달된 이후 수행되는 경우가 많다.  
 

지속적 제공 파이프라인 내의 단계 

지속적 제공은 애플리케이션을 하나 이상의 제공 환경으로 푸시하는 자동화다. 개발팀은 일반적으로 테스트 및 리뷰를 위해 애플리케이션 변경을 준비하는 여러 환경을 둔다. 데브옵스 엔지니어는 젠킨스(Jenkins), 서클CI(CircleCI), AWS 코드빌드(CodeBuild), 애저 데브옵스(DevOps), 아틀라시안 뱀부(Bamboo), 아르고 CD(Argo CD), 버디(Buddy), 드론(Drone), 트래비스 CI(Travis CI)와 같은 CI/CD 툴을 사용해서 이와 같은 단계를 자동화하고 보고한다. 

일반적인 지속적 제공 파이프라인에는 빌드, 테스트, 배포 단계가 있다. 다음 활동은 다양한 단계에 포함될 수 있다. 
 

• 버전 제어에서 코드를 풀링해서 빌드 실행 
• 단계 게이트에서 자동화된 보안, 품질 및 규정 준수 확인과 필요한 경우 이를 뒷받침하는 승인 활성화. 
• 코드로 자동화된 필요 인프라 단계를 실행해 클라우드 인프라 구축 또는 해체 
• 타깃 컴퓨팅 환경으로 코드 이동 
• 환경 변수를 관리하고 타겟 환경에 맞게 구성 
• 애플리케이션 구성요소를 웹 서버, API, 데이터베이스 서비스와 같은 적절한 서비스로 푸시 
• 새 코드 푸시에 필요한 서비스 엔드포인트를 호출하거나 서비스를 재시작하기 위해 필요한 단계 실행 
• 지속적 테스트 실행과 테스트 실패 시 롤백 
• 제공 상태에 대한 로그 데이터 및 알림 제공 
• 구성 관리 데이터베이스를 업데이트하고 IT 서비스 관리 워크플로우에 완료된 배포에 대한 알림 전송 

더 세밀한 지속적 제공 파이프라인에는 데이터 동기화, 정보 리소스 아카이빙, 애플리케이션 및 라이브러리 패치와 같은 부가적인 단계도 포함될 수 있다. 

지속적 배포를 사용하여 프로덕션으로 배포하는 팀은 다운타임을 최소화하고 배포 위험을 관리하기 위해 다양한 방법을 사용할 수 있다. 한 가지 옵션은 이전 소프트웨어 버전에서 새 버전으로 트래픽 사용의 전환을 조율하는 카나리 배포를 구성하는 것이다.