지속적 통합 vs 전달 vs 배포

지속적 통합은 코드를 모두 취합해 테스트하기까지 완벽한 코드를 기다리지 않고 개발 프로세스 전반에 걸쳐 "통합" 중 수행된 단계를 조금씩, 자주 실행하는 관행입니다.

대부분의 상용 및 오픈소스 소프트웨어에서 일반적인 것처럼 두 명 이상이 소프트웨어 제품을 개발하는 상황을 가정할 경우, 언젠가 각각의 개발자가 작업한 부분을 결합하여 최종 결과물이 적절히 작동하는지 확인해야 할 시점이 도래합니다. 지속적 통합이 적용된 경우 그 시점은 하루에 한 번 이상 발생합니다.

이유는 간단합니다. 모든 코드가 작성될 때까지 통합을 방치할 경우 코드 섹션을 살펴보고 다시 작성하는 데 상당한 시간이 소요될 가능성이 높으며, 이러한 상황은 솔루션이 적절히 작동하는지 확인하는 것은 물론 빌드를 완료하는 데도 발생합니다. 코드는 복잡합니다. 세밀한 사전 설계 작업을 거쳤더라도 로직의 상호작용 및 문제 방지 방식을 정확히 예측하는 것은 매우 어렵습니다. 코드가 많을수록 더욱 복잡해지며 작동하지 않는 부분이 있을 때 다시 살펴봐야 할 분량도 증가합니다.

지속적인 통합을 사용하면 개발자는 변경 사항을 정기적으로(1일 1회 이상) 소스 관리 시스템에 커밋하여 변경 사항을 공유하고, 솔루션의 테스트 빌드 및 통과 현황을 확인합니다. 그러므로 문제가 발생하면 문제의 원인을 파악하기 위해 점검해야 할 변경 사항의 개수가 더 적습니다. 또한 신속한 피드백이 제공되므로 수행 중인 작업의 컨텍스트를 놓치지 않으며 훨씬 간편하게 이슈를 수정할 수 있습니다.

좋은 CI 프로세스의 몇 가지 필수 요소는 다음과 같습니다.

이와 같은 모든 요소를 함께 활용하면 코드에 대한 피드백을 빠르게, 정기적으로 받을 수 있습니다. 버그 수정, 리팩터링 또는 신규 기능의 일부 혹은 테스트를 통과한 클린 빌드 결과 등 코드베이스의 모든 변경 사항을 확인함으로써 팀은 부적절한 기반에서 새로운 일을 수행하면 필연적으로 수반되는 재작업을 방지할 수 있습니다. 지속적 통합의 자체적 구현은 작동하는 소프트웨어를 사용자에게 전달하기 위한 프로세스의 속도를 개선하는 큰 변화입니다.

지속적 전달은 지속적 통합으로 확립된 빌드 및 테스트 자동화의 토대를 기반으로 삼습니다.

지속적인 전달을 활용하면 소프트웨어 빌드를 프로덕션으로 출시하는 데 사용되는 수동 단계를 자동화된 프로세스로 전환할 수 있습니다.

이전에는 개발자에서 테스터로, 테스터에서 릴리스 관리자로 핸드오프가 제공되었지만 지속적인 전달을 도입하면 다양한 분야의 사람들이 포함된 팀으로 빌드, 테스트 및 제품 릴리스의 전체 프로세스를 완전히 파악할 수 있습니다. 지속적인 전달의 이점은 다음과 같습니다.

• 기존의 사일로를 방지하므로 사용자에게 제품을 제공하기 위한 비즈니스 및 운영상 요구 사항을 개발 팀에서 더욱 잘 이해할 수 있습니다.
• 따라서 대체로 수동으로 진행되는 긴 호흡의 프로세스에 개발 관행을 도입할 기회를 제공합니다.
• 제품을 라이브로 전달하는 단계를 자동화하면 프로세스 속도를 개선할 수 있을 뿐 아니라 오류 위험이 감소하여 더욱 안정적이고 신뢰할 수 있는 프로세스가 구축됩니다.

사용자에게 소프트웨어를 제공하는 정확한 단계(즉, 전달 파이프라인의 필수 단계)는 비즈니스 및 사용자의 니즈에 따라 다르지만 실제 릴리스에 앞서 하나 이상의 사전 프로덕션 환경으로 배포하는 것이 일반적입니다.

이러한 환경은 보안, 로드, 성능 테스트와 같은 추가 테스트 계층을 위한 테스트 환경, 지원 및 영업팀에서 새로운 기능을 익힐 수 있는 샌드박스 환경, 변경 사항의 적절한 작동을 확인하는 QA 및 제품 전문가를 위한 수용 테스트 환경일 수 있습니다.

지속적 전달을 활용하면 성공적인 각각의 빌드가 각 사전 프로덕션 환경에 자동으로 배포되며, 모든 단계별로 품질이 개선된다는 확신을 얻을 수 있습니다.

이는 실행하는 데 약간의 투자를 필요로 하지만 추구할 만한 목표입니다.

지속적 전달을 통해 팀은 소프트웨어 제공을 위한 책임을 다하고 프로세스 전반에서 적절한 시기에 제공되는 피드백의 이점을 누릴 수 있습니다. 지속적인 통합과 마찬가지로 시간이 지날수록 이 관행이 구축되고 개선될 수 있습니다.

지속적 배포는 지속적 통합 및 전달의 관행의 논리적 귀결입니다.

빌드가 파이프라인의 모든 이전 단계를 무사히 통과할 경우 프로덕션에 자동으로 릴리스됩니다. 즉, 소프트웨어의 변경 사항이 모든 테스트를 통과하는 즉시 사용자에게 전달되는 것입니다. 지속적 배포는 프로덕션에 사용할 수 있도록 코드 변경의 피드백 루프를 단축하므로 품질 저하 없이 변경된 사항이 실제 환경에서 실행되는 방식에 대한 인사이트를 적시에 제공합니다.

프로덕션으로의 소프트웨어 배포 자동화가 모든 제품과 조직에 적합하지는 않지만 각각의 개별적 요소가 그 자체로 가치를 지니므로 이를 달성하는 데 필요한 단계를 고려하는 것이 좋습니다.

지속적 통합, 전달 및 배포는 모두 가치 있고 작동하는 소프트웨어를 사용자에게 빈번히 제공한다는 목표에 부합합니다. 통합 및 릴리스를 조금씩, 자주 수행하는 접근 방식을 통해 프로세스를 보다 쉽게 관리할 수 있으며 팀은 이러한 단계를 정기적으로 실천하며 발전할 수 있습니다.

자동화 도입으로 프로세스의 속도뿐 아니라 신뢰도도 향상됩니다. 파이프라인의 각 단계는 이전 단계를 기반으로 구성되며 개발자는 언제든 적합한 정도를 선택하고 추후 다시 빌드할 수 있습니다.