CI/CD 시작하기 : CI/CD 파이프라인으로 애플리케이션 딜리버리 자동화

그런 다음 프로덕션에 투입할 만큼 준비된 변경 사항과 기능을 더 효과적으로 통제하기 위한 여러 가지 방법론을 도입한다. 아주 작은 변경의 경우, 모든 테스트가 통과되고 변경 사항을 언제든 프로덕션에 배포할 수 있다는 요구 사항이 충족되면 주 개발 분기에 체크인할 수 있다. 규모가 비교적 큰 개발 작업의 경우 기능 플래그를 도입한다. 기능 플래그는 사용자에게 보이지 않는 기능 코드를 배포하기 위한 방법이다. 기능 플래그는 제품이 개발 및 테스트 환경에 배포될 때 활성화하고 프로덕션에서는 비활성화할 수 있다. 더 큰 개발 작업 또는 프로덕션 핫픽스의 경우 깃플로(Gitflow)에 따르면서 팀을 대상으로 깃에서 기능 및 핫픽스 분기를 활용하는 방법을 교육할 수 있다.

이러한 여러 방법을 조합해서 릴리즈 관리 전략을 수립한다. 팀은 기술 부채를 가장 먼저 해결하고 이를 처음 몇 차례의 주별 릴리즈에 걸쳐 프로덕션으로 릴리즈하기로 합의한다. 그런 다음 애자일 추정 및 기타 기법을 사용해서 개발 분기에 넣을 기능, 기능 플래그를 사용할 기능, 기능 분기에서 개발할 한 가지의 복잡한 추가 개선 사항을 결정한다.

지속적 딜리버리(CD), 변경 사항 푸시 표준화 및 자동화
지속적 통합이 구현되고, 일부 팀원은 서둘러 개발을 시작하고자 한다. 그러나 시스템 엔지니어는 빌드와 테스트가 자동화되었지만 애플리케이션 및 데이터베이스 변경을 프로덕션과 기타 환경에 푸시하기 위한 단계는 아직 자동화되지 않았다는 이유로 서두르기를 주저한다.

엔지니어는 새 애플리케이션을 푸시할 때 수동과 자동이 섞인 프로세스를 사용한다. 이를 롤백하기 위한 프로세스는 더 복잡하다. 또한 모든 배포가 이전 배포와 조금씩 달라서 변경의 유형에 따라 이러한 절차를 검토하고 업데이트해야 한다. 엔지니어는 프로세스 단계가 완벽하게 문서화되지 않은 탓에 자신이 배포를 망친 사람으로 지목되는 상황에 진력이 난다.

팀이 지속적 딜리버리에 투자하지 않으면 엔지니어는 개발 및 기능 분기에서 실행되는 주별 푸시와 변경 사항 조합 테스트를 지원할 수 없다.

엔지니어에게 좋은 소식도 있다. 이미 코드로서의 인프라(Infrastructure as a Code)에 투자했고 덕분에 일관적으로, 손쉽게 새로운 환경을 설정할 수 있다. 당면한 과제는 애플리케이션 변경 사항을 이러한 환경으로 일관적으로 푸시하는 방법이다.

지속적 딜리버리 툴을 선택한 후 팀은 먼저 환경별 정보를 애플리케이션에서 추출하기 위해 일부 코드를 변경해야 한다. 즉 환경 변수, 엔드포인트, 사용자 이름과 암호, 그리고 환경에 의해 구성되고 지속적 딜리버리 툴에서 정의되는 변수를 사용하는 데 필요한 기타 런타임 변수가 여기에 해당된다. 구성을 더 쉽게 관리하기 위해 팀은 환경 변수의 합의된 명명 규칙을 마련한다.

또한 수작업으로 진행되는 몇몇 배포 전후 단계를 스크립트화해서 지속적 딜리버리 툴에 의해 실행이 가능하도록 해야 한다. 데이터 변경을 푸시하고 서비스 구성을 동기화하거나 데이터베이스 인덱스를 실행하기 위한 단계는 이제 자동화되며 자체 검증된다. 또한 팀은 성능과 보안 테스트를 자동화해서 환경에 딜리버리되기에 앞서 테스트가 통과되도록 한다. 마지막으로, 딜리버리 프로세스의 모든 단계에는 딜리버리가 실패하고 롤백해야 할 경우 실행되는 대응 단계가 존재한다.

팀은 컨테이너 기술을 사용해서 애플리케이션을 구성하고 도커, 쿠버네티스, 윈도우 서버 컨테이너 및 기타 컨테이너 기술을 사용할 때 얻는 이점에 대해 토론한다. 이를 통해 모든 애플리케이션 서비스가 균일하게 구성 및 패키징되고 일관적으로 구축되도록 보장한다.

또한 지난 릴리즈에서 경험한 데이터 문제에 대해 더 연구한다. 프로덕션 데이터는 항상 변경되는데, 이 데이터를 개발 및 테스트 환경으로 미러링하려면 어떻게 해야 할까? 이것도 스크립트화해서 일정에 따라, 또는 필요할 때 프로덕션 데이터를 마스킹하고 개발 및 테스트 환경에 전달한다.

이후 환경에 필요한 사항을 재고한다. 하나의 개발 환경을 두는 대신 새 기능 분기에 따라 전용 환경이 생성되도록 한다. 이렇게 해서 이 환경에 배포하는 데 필요한 구성과 분기를 개발한다. 또한 팀은 두 개의 테스트 환경을 설정하기로 결정한다. 하나는 데이터를 표준화하고 안정적인 데이터 집합을 기준으로 기능을 테스트하는 환경, 다른 하나는 성능 테스트를 위해 전체 프로덕션 데이터가 있는 환경이다.

바이트 크기의 증분으로 CI/CD 구축
현실에서 대부분의 조직은 CI/CD 방식을 단번에 성숙 단계로 발전시킬 수도 없고, 그 단계에 이를 때까지 비즈니스 요구 사항을 보류할 수도 없다. 즉, 개발 조직은 버스가 달리는 중에 버스의 바퀴를 교체해야 한다.

또한 팀의 현재 기술 수준 또는 시간적 제약으로 인해 레거시 애플리케이션을 CI/CD 파이프라인으로 손쉽게 변환할 수 없는 경우가 많다.

따라서 대부분의 조직은 가장 중요한 문제에 대처하고 가장 큰 기술적 장애물을 피하기 위한 방법과 자동화부터 시작한 다음 이후 장기간에 걸쳐 CI/CD를 발전시킨다.

처음 시작하기에 좋은 방법은 문제와 기회를 정의하고 우선 순위를 부여하는 것이다. 그러면 팀은 애자일 백로그에서 데브옵스를 확고히 하고 장기간에 걸쳐, 비즈니스 요구에 대처하는 동시에 CI/CD 파이프라인 요소를 개발할 수 있다.

*Isaac Sacolick 은 StarCIO의 사장이며 “드라이빙 디지털: 기술을 통한 비즈니스 트랜스포메이션을 위한 리더 가이드(Driving Digital: The Leader’s Guide to Business Transformation through Technology)”의 저자이다.
editor@itworld.co.kr