지속적 통합 및 지속적 전달/배포란 무엇입니까?

이 단원에서는 지속적 통합 및 지속적 전달의 관행에 대해 알아보고 지속적 전달과 지속적 배포의 차이점에 대해 설명합니다.

지속적 통합

지속적 통합(CI)은 개발자가 코드 변경 사항을 정기적으로 중앙 리포지토리에 병합한 후 자동 구축 및 테스트를 실행하는 소프트웨어 개발 방식입니다. CI는 대부분 소프트웨어 릴리스 프로세스의 빌드 또는 통합 단계를 의미하며 자동화 구성 요소(예: CI 또는 빌드 서비스)와 문화적 요소(예: 작은 통합)가 필요합니다. CI의 핵심 목표는 버그를 신속하게 찾아 해결하고, 소프트웨어 품질을 향상하고, 새로운 소프트웨어 업데이트를 검증 및 릴리스하는 데 걸리는 시간을 단축하는 것입니다.

지속적인 통합은 더 작은 커밋과 통합할 더 작은 코드 변경에 중점을 둡니다. 개발자는 최소 하루에 한 번 정기적으로 코드를 커밋합니다. 개발자는 코드 리포지토리에서 코드를 가져와 빌드 서버로 푸시하기 전에 로컬 호스트의 코드가 병합되었는지 확인합니다. 이 단계에서 빌드 서버는 다양한 테스트를 실행하고 코드 커밋을 승인하거나 거부합니다.

CI 구현의 기본 과제로는 공통 코드베이스에 대한 커밋 빈도 증가, 단일 소스 코드 리포지토리 유지 관리, 빌드 자동화 및 테스트 자동화 등이 있습니다. 추가 과제로는 프로덕션과 유사한 환경에서 테스트하고, 팀에 프로세스 가시성을 제공하고, 개발자가 애플리케이션의 모든 버전을 쉽게 얻을 수 있도록 하는 것입니다.

지속적 전달 및 배포

지속적 전달(CD)은 코드 변경 사항이 자동으로 빌드, 테스트 및 프로덕션 릴리스에 맞게 준비되는 소프트웨어 개발 방식입니다. 빌드 단계가 완료된 후 모든 코드 변경 사항을 테스트 환경, 프로덕션 환경 또는 둘 다에 배치함으로써 지속적인 통합으로 확장됩니다. 지속적 전달은 워크플로 프로세스를 통해 완전히 자동화되거나 중요한 시점에서 수동 단계를 통해 부분적으로 자동화될 수 있습니다. 지속적 전달이 적절하게 구현되면 개발자는 언제나 즉시 배포할 수 있고 표준화된 테스트 프로세스를 통과한 빌드 아티팩트를 보유하게 됩니다.

지속적인 배포를 통해 개발자의 명시적인 승인 없이 수정 버전이 프로덕션 환경에 자동으로 배치되어 전체 소프트웨어 릴리스 프로세스가 자동화됩니다. 이를 통해 제품 수명 주기 초기에 지속적인 고객 피드백 루프가 가능합니다.

지속적 배포가 아닌 지속적 전달

지속적 전달에 대한 오해 중 하나는 커밋된 모든 변경 사항이 자동화된 테스트를 통과한 직후 프로덕션에 적용된다는 것입니다. 그러나 지속적인 전달의 요점은 모든 변경 사항을 프로덕션에 즉시 적용하는 것이 아니라 모든 변경 사항을 프로덕션에 적용할 준비가 되었는지 확인하는 것입니다.

프로덕션에 변경 사항을 배포하기 전에 결정 프로세스를 구현하여 프로덕션 배포가 승인되고 감사되는지 확인할 수 있습니다. 사용자가 이러한 결정은 내린 다음 도구로 실행할 수 있습니다.

지속적 전달을 통해 준비된 결정은 기술적 결정이 아닌 비즈니스 결정이 됩니다. 기술 검증은 모든 커밋에서 이루어집니다.

프로덕션에 변경 사항을 도입하는 것은 지장을 주지 않습니다. 배포 시 기술 팀은 다음 변경 작업을 중단할 필요가 없으며 프로젝트 계획, 인계 문서 또는 유지 관리 기간이 필요하지 않습니다. 배포는 테스트 환경에서 여러 번 수행되고 검증된 반복 가능한 프로세스가 됩니다.