지속적인 배포 이해
지속적 배포(CD)는 성공적인 코드 변경 사항을 자동으로 프로덕션에 배포하여 지속적 통합 및 지속적 전달(CI/CD) 프로세스를 확장합니다.
지속적 배포란?
지속적 배포는 빌드, 테스트 및 배포 단계를 자동화하는 DevOps 방식의 논리성을 극대화합니다. 코드 변경 사항이 파이프라인의 모든 단계를 성공적으로 통과하면 해당 변경 사항은 수동 개입 없이 자동으로 프로덕션에 배포됩니다. 지속적 배포를 채택하면 품질 저하 없이 최대한 빨리 사용자에게 새로운 기능을 제공할 수 있습니다.
지속적 배포는 성숙하고 잘 테스트된 지속적 통합 및 지속적 전달 프로세스를 기반으로 합니다.
- 팀원들이 코드 변경 사항을 소규모 배치로 정기적으로 커밋합니다.
- 커밋할 때마다 자동화된 테스트 및 빌드 프로세스가 트리거됩니다.
- 그러면 빌드가 다양한 사전 프로덕션 환경을 거치면서 추가적인 자동화 테스트를 받습니다.
- 문제가 발견되지 않으면 새로운 버전의 소프트웨어가 사용자에게 전달됩니다.
강력하고 안정적인 CI/CD 프로세스가 구축되면 마지막 단계를 자동화하여 사용자에게 자동으로 변경 사항을 배포할 수 있습니다. 지속적 배포를 통해 하루에도 여러 번 특별할 것 없는 릴리스가 발생하게 됩니다.
지속적 배포를 모든 DevOps 팀의 최종적 목표로 여겨서는 안 됩니다. 앱, API 또는 설치형 소프트웨어를 빌드하는 경우 사용자는 하루에 여러 번 업데이트를 받는 것을 원하지 않을 수도 있습니다. 이런 경우에는 지속적 전달이 더 적합할 수 있습니다.
완전히 자동화된 배포 파이프라인은 아니더라도 일부 방식을 선택하여 자체 CI/CD 프로세스에 적용할 수 있습니다. 지금부터 지속적 배포에서 이루어지는 작업은 정확히 무엇이고, 모든 것을 지속적 배포로 전환하기 전에 고려해야 할 사항은 무엇인지 알아보겠습니다.
지속적 배포와 지속적 전달 비교
이 두 가지를 혼동하기 쉽지만 지속적 배포와 지속적 전달은 모두 CI/CD 파이프라인의 CD 면에서 구분됩니다. 지속적 전달에서는 프로덕션으로 최종 릴리스를 보낼 때 수동으로 트리거해야 하지만 지속적 배포에서는 이전 단계가 모두 성공적으로 완료되었다면 릴리스가 자동으로 이루어집니다.
지속적 배포와 지속적 전달 비교
| 지속적 배포 | 지속적 전달 | |
|---|---|---|
| 릴리스 모델 | 코드 변경이 파이프라인의 각 단계를 성공적으로 마칠 때마다 자동으로 트리거됩니다. | 파이프라인의 각 단계를 성공적으로 마친 변경 사항에 대해 수동으로 실행합니다. |
| 릴리스 빈도 | 시간당 최대 여러 번(팀 규모와 파이프라인 속도에 따라 다름) | 일반적으로 매주 또는 매달이지만, 원하는 만큼 자주 또는 드물게 수행할 수 있습니다. |
| 적합한 대상 | 웹사이트 및 웹 애플리케이션 | 모바일 앱, 데스크톱 소프트웨어 및 API. 지속적 배포를 위한 기반으로 이용할 수도 있습니다. |
| 테스트 프로세스 | 완전 자동화되고 매우 강력해야 합니다. 품질 게이트를 통해 개발자와 이해 관계자는 테스트로 버그가 파악된다고 확신할 수 있습니다. | 최대한 자동화된 테스트를 이용하는 것이 좋습니다. 릴리스 빈도가 적어 수동 승인 및 탐색적 테스트를 수행해야 할 여지가 생깁니다. |
| 추가 고려 사항 | 카나리아 배포와 블루/그린 빌드로 프로덕션에 릴리스되는 문제의 영향을 최소화할 수 있습니다. 프로덕션에서 최대한 일찍 문제를 식별하려면 모니터링이 필수적입니다. | 릴리스는 수동으로 트리거하더라도 프로세스 자체는 자동화되어야 합니다. 빠르게 롤백하거나 수정 사항을 배포하는 옵션도 여전히 고려해야 합니다. |
지속적 통합, 전달 및 배포 가이드에서 차이점을 자세히 알아보세요.
지속적 배포 실현하기
통합 및 배포 프로세스를 완전히 수동으로 진행하면서 코드를 동결하고 테스트 전략에 모두가 매달려 출시일에 숨을 죽이고 걱정하는 상황이라면 매시간 배포가 비현실적으로 들릴 수 있습니다.
하지만 현실적으로 많은 조직이 더 정기적인 접근 방식으로 전환하고 있습니다. Netflix, Etsy, Amazon과 같은 대기업부터 덜 알려진 소규모 기업까지 많은 기업들이 시장 동향에 발 맞추기 위해 지속적 배포 시스템을 도입하고 있습니다. 이 방법을 통해 많은 소프트웨어 개발사는 릴리스 기간을 몇 주 혹은 몇 달에서 몇 시간으로 단축하고 있습니다.
신속하게 기능을 제공하고 피드백에 대응해야 하는 현실에서 지속적 배포는 품질을 떨어뜨리지 않으면서 정기적으로 릴리스할 수 있는 전략을 제공합니다.
지속적 배포 시스템 구현
지속적 통합과 전달의 연장선에 있는 지속적 배포는 완전 자동화된 빌드, 테스트 및 배포 프로세스를 이용합니다. 이 접근 방식은 속도를 위해 품질을 타협하지 않습니다. 그러나 지속적 배포를 효과적으로 구현하려면 견고한 기반 그 이상이 필요합니다.
품질 게이트
수동 개입 없이 변경 사항을 릴리스하려면 CI/CD 프로세스에 대한 완전한 확신이 있어야 합니다. 특히 자동 빌드와 자동 테스트로 코드가 효과적으로 검증되는지 확인해야 합니다. 이 단계에서는 코드 품질 게이트가 도움이 될 수 있습니다.
품질 게이트는 코드가 파이프라인의 다음 단계로 진행되기 위한 기준을 지정합니다. 일부 단계에서는 유닛 테스트에 90% 코드 커버리지와 100% 통과율을 요구하는 등 간단한 기준을 설정할 수 있습니다. 다른 자동화된 테스트의 경우, 오류가 발생했을 때는 일정 비율의 경고는 허용하면서 해당 단계를 실패로 처리할 수 있습니다. 때로는 단계를 실패로 처리하기 전에 오류나 경고에 수동 검토가 필요한 것으로 플래그 지정하고 싶을 수 있습니다.
파이프라인의 핵심 단계에 자동화된 품질 게이트를 사용하면 프로세스를 제어하고 가시성을 확보할 수 있으며 각 릴리스에서 수행된 검토에 대한 완벽한 감사 추적이 가능합니다.
릴리스 전략 고려
지속적 배포 시스템을 구현할 방법을 계획할 때 핵심적으로 고려해야 할 점은 변경이 릴리스되는 방식입니다. 배포할 때마다 서버를 오프라인으로 전환하면 온라인 서비스가 자주 중단되므로 롤링 업데이트 전략이 바람직한 경우가 많습니다. 카나리아 배포를 이용해 롤아웃을 자동화된 테스트 프로세스의 연장선으로 만들 수도 있습니다.
카나리아 배포
카나리아 배포는 업데이트된 코드의 배포 대상을 소수의 사용자로 제한하여, 이들을 프로덕션 환경에서 무의식적 테스터가 되도록 합니다. 사용자 행동 및 사용 현황 메트릭을 모니터링하여 새 릴리스를 더 광범위하게 배포하기 전에 여기에 새로운 오류가 유입되었는지 여부를 확인할 수 있습니다.
카나리아 신뢰 점수
일부 회사는 광범위한 메트릭을 기준선과 자동으로 비교하는 카나리아 신뢰도 점수를 이용해 자동화를 더 강화합니다. 자동화된 롤아웃은 점수가 지정된 임곗값을 넘는 경우에만 계속됩니다. 점수가 너무 낮으면 메트릭 분석을 통해 잠재적인 문제를 심층적으로 조사할 수 있습니다.
블루/그린 빌드 배포
블루/그린 빌드 배포 프로세스는 지속적 배포 시스템을 구현하는 조직에서 일반적으로 사용하는 기술입니다. 블루/그린 배포를 사용하면 변경 사항이 예상대로 작동하는지 확인될 때까지 이전 코드를 온라인 상태로 유지할 수 있으므로 문제 발생 시 릴리스를 롤백하기가 더 쉽습니다. 필요한 경우 블루/그린 롤아웃으로 초기 카나리아 배포를 진행할 수도 있습니다.
프로덕션 메트릭 모니터링
블루/그린 배포를 실행하거나 직접 대체물을 롤아웃하는 모든 경우에 자동화된 테스트 프로세스에서 걸러내지 못한 버그에 신속하게 대응하려면 프로덕션 시스템의 상태를 모니터링해야 합니다.
먼저, 시스템 상태를 나타내는 주요 메트릭을 확인합니다. 여기에는 디스크 공간 및 CPU 사용량 등의 시스템 상태 메트릭과 요청 또는 트랜잭션 수 등의 사용 현황 메트릭이 포함될 수 있습니다. 이러한 메트릭을 정상값과 비교하면 상황이 제대로 진행되지 않을 경우 조기에 경고 신호를 받을 수 있습니다. 그런 다음 변경 사항을 롤백할지, 파이프라인을 통해 수정 사항을 적용할지 결정할 수 있습니다.
지속적 배포를 위한 고려 사항
지속적 배포를 본격적으로 도입하기 전에 성공적 도입을 위해 몇 가지 해야 할 일을 생각해 보아야 합니다.
이해 관계자 참여
소프트웨어 개발 수명 주기는 단순히 코드 변경에만 관련된 것이 아닙니다. 사용자 조사, 제품 마케팅, 상호 작용 디자인, 문서화, 상업, 법률 및 지원 팀 모두가 해야 할 역할이 있습니다.
릴리스 과정에서 이해 관계자의 요구 사항을 이해하기 위한 참여와 소통의 토대를 마련하지 않는다면 자동화된 릴리스로의 전환은 이들에게 통제되지 않은 개발처럼 느껴질 수 있습니다. 이때 이해 관계자들은 수동 체크포인트와 검토 단계를 요구할 수 있으며, 이로 인해 프로세스가 느려지고 CI/CD의 이점이 퇴색될 수 있습니다. 최악의 경우, 지속적 배포 시스템이 실패한 실험으로 완전히 거부될 수도 있습니다.
협업 장려
지속적 배포가 제대로 작동하려면 협업의 문화를 마련해야 합니다. 예를 들어 설계, 보안 문제, 용어 또는 규정 준수에 대한 의견을 초기에 통합할 수 있도록 개발 프로세스 전반에 걸쳐 다른 팀을 참여시키는 등의 간단한 피드백 순환을 통해 소프트웨어 개발 수명 주기를 더 효율화할 수 있습니다.
모두와 정보 공유
의견을 수렴하는 것만큼이나 중요한 것은 언제 무엇을 릴리스하는지 명확히 알 수 있도록 하는 것입니다. CI 서버를 통해 이해 관계자와 자동으로 정보를 공유하세요. 선택한 지속적 빌드 배포 도구에 따라 대시보드와 알림을 통해 정보를 전달할 수 있어야 합니다.
기능 플래그 또는 전용 브랜치 사용
때로는 무엇이 예정되어 있는지 알려주는 것만으로는 충분하지 않습니다. 큰 기능을 작업 중이거나 릴리스 시기를 관리해야 하는 경우, 각 커밋을 모든 테스트 통과 즉시 라이브로 배포하는 것은 이상적이지 않습니다.
기능 플래그는 프로덕션 환경에서 코드의 가시성을 제어하는 한 가지 방법입니다. 이 방법의 장점은 코드가 라이브 상태이므로 예상치 못한 오류가 발생하는지 소프트웨어를 모니터링할 수 있다는 것입니다.
또 다른 방식은 프로덕션으로 자동 푸시되지 않는 전용 브랜치와 별도 파이프라인을 사용하여 필요에 따라 지속적 전달과 지속적 배포를 결합하는 것입니다.
지속적 배포 모범 사례
제대로만 하면 지속적 배포를 통해 버그를 최소화하면서 사용자에게 변경 사항을 더 자주 전달할 수 있습니다. 여기서 핵심은 메트릭을 사용하여 파이프라인을 최적화하고 프로덕션 환경에서 문제의 징후가 있는지 모니터링하는 등의 모범 사례를 따르는 것입니다. 또한, 관련된 문화적 변화를 인식하고 전체 팀을 CI/CD 프로세스에 참여시키는 것도 중요합니다.
지속적 배포 모범 사례 가이드에서 CI/CD 프로세스를 간소화하고 더 나은 결과를 얻는 방법에 대해 자세히 알아볼 수 있습니다.
요약
- 지속적 배포는 빌드, 테스트 및 릴리스 프로세스의 모든 단계를 자동화하는 일종의 DevOps입니다.
- 지속적 배포의 목적은 품질의 타협 없이 사용자에게 기능을 더 빠르게 더 자주 제공하는 것입니다.
- 지속적 배포는 사용자가 직접 업데이트를 적용할 필요가 없으므로 웹사이트와 웹 애플리케이션에 특히 적합합니다.
- 더 빠르고 빈번한 릴리스를 통해 사용자로부터 신속하게 피드백을 받고, 발견되지 못한 채 프로덕션으로 유입되는 버그의 영향을 줄일 수 있습니다.
- 자동화된 테스트, 프로덕션 모니터링, 다른 직무자와의 협업 및 사용자 행동 모두가 소프트웨어 개발 프로세스에 피드백을 제공합니다.
- 더 세분화된 단위로 작업하고 자주 릴리스하면 피드백을 기반으로 계속 조정하고 전달하는 내용을 지속적으로 개선할 수 있습니다.
TeamCity의 이점
TeamCity에는 구성이 매우 자유로운 트리거 옵션과 배포 빌드 러너가 있어 지속적 배포를 설정하기가 쉽습니다. 전용 배포 빌드 구성을 사용하면 프로덕션에 대한 배포 권한을 제한할 수 있고, 유연한 빌드 트리거를 통해 릴리스 조건을 정의할 수 있습니다. TeamCity에서는 패키지 저장소 및 컨테이너 레지스트리를 기본적으로 지원하므로 빌드 아티팩트가 지속적 배포 프로세스의 일부로 관리됩니다.
이해 관계자가 TeamCity의 직관적인 웹 기반 대시보드에 액세스할 수 있게 하여 진행 상황을 공유할 수도 있습니다. 강력한 역할 기반 액세스 제어로 프로덕션 경로가 보호되고 내장된 감사 추적 기능이 파이프라인의 모든 활동을 포괄적으로 기록합니다.
