지속적 통합 vs 전달 vs 배포

먼저 CI와 CD의 주요 특징과 차이점을 살펴보겠습니다.

지속적 통합(CI)

지속적 통합(CI)은 작업에 대한 빠른 피드백을 얻기 위해 코드 변경 사항을 자동으로 확인하는 방법입니다. CI를 사용하면 변경 사항을 커밋할 때마다 CI 서버가 빌드를 실행하고 자동화된 테스트를 실행합니다. 이러한 테스트에는 일반적으로 유닛 테스트, 통합 테스트 및 린트나 정적 분석과 같은 기타 검사가 포함됩니다. CI 프로세스의 어떤 단계가 실패하면 자동으로 피드백을 받아 문제를 해결할 수 있습니다. 수정 사항을 커밋하면 이 프로세스가 다시 시작됩니다.

지속적 전달 및 지속적 배포

지속적 전달과 지속적 배포의 차이는 프로덕션으로 릴리스하는 최종 단계에 있습니다.

지속적 전달의 경우, 빌드 아티팩트를 프로덕션으로 릴리스하려면 수동 작업이 필요합니다. 릴리스 프로세스는 일반적으로 완전히 자동화되어 있지만 특정 빌드의 릴리스 여부와 시기를 누군가가 결정해야 합니다. 이와 달리, 지속적 배포의 경우에는 이전 프로세스 단계를 완료할 때마다 빌드가 프로덕션으로 자동 릴리스됩니다.

지속적 전달과 지속적 배포 중 선택

지속적 전달과 지속적 배포 중 어떤 것이 더 적합한지 여부를 결정하는 것은 상황에 달려 있습니다.

모바일 앱이나 API와 같은 소프트웨어 제품의 경우, 커밋에 성공할 때마다 새 버전을 릴리스하는 것은 이상적이지 않을 수 있습니다. 대신, 일정에 따라 릴리스하거나 배포할 최소한의 변경 사항이 준비될 때까지 기다리는 것이 더 바람직할 수도 있습니다.

이 경우, 지속적인 전달을 사용하여 변경 사항을 확인하고 사전 프로덕션 환경에서 릴리스를 미리 볼 수 있습니다. 또한 지속적 전달의 경우에는 매번 릴리스하기 전에 수동 승인 테스트를 실시할 수도 있습니다.

한편, 지속적 배포는 하루, 심지어 시간 단위로 빈번하게 업데이트하는 것이 일반적인 웹 기반 앱 및 서비스에 적합합니다.

지속적 배포를 이용하면 조금씩 업데이트를 제공하고 즉각적으로 피드백을 받을 수 있습니다. 또한 지속적인 배포를 사용하면 실제 사용자를 대상으로 실험을 실행하고 가정을 검증할 수 있으며, 필요에 따라 새로운 릴리스로 신속하게 방향을 전환할 수 있습니다.

마지막으로, 일부 수동 승인과 탐색적 테스트를 지속적인 배포 프로세스에 통합할 수 있다는 점을 알아두어야 합니다.

릴리스하기 전에 매번 수동으로 검사하는 대신, 주기적으로 스테이징 환경에 변경 사항을 배포하고 매주(또는 그 이상) 주기로 이러한 테스트를 수행할 수 있습니다.

한편, 모든 자동 검사를 통과하는 변경 사항은 프로덕션으로 계속해서 릴리스할 수 있습니다. 스테이징에서 문제점이 발견되면 자동화된 파이프라인의 도움으로 수정 사항을 프로덕션으로 신속하게 배포할 수 있습니다.

CI/CD는 소프트웨어를 빌드, 테스트 및 릴리스하는 과정에서 거치게 되는 두 단계입니다.

CI/CD 파이프라인은 코드에 대한 신뢰도를 점진적으로 높여주는 도구입니다.

각 단계에서 성공을 거두면서 확신이 굳어지면 만족스러운 상태로 사용자에게 코드를 릴리스하게 됩니다. 하지만 어떤 단계에서 실패하는 경우 빌드 프로세스를 중단하고 버그를 수정하거나 변경을 취소해야 합니다. 문제가 해결되면 처음부터 프로세스가 다시 시작됩니다.

빌드, 테스트, 릴리스 프로세스의 첫 번째 단계인 CI에서는 검사를 통한 빠른 피드백에 중점을 둡니다. 코드 변경에 대한 빠른 피드백을 받으면 컨텍스트 전환 필요성을 줄여 더 효율적으로 작업할 수 있습니다. 수동 테스트 결과를 몇 시간 또는 며칠씩 기다리는 대신 변경으로 인해 발생한 문제에 대해 몇 분 내에 알림을 받게 됩니다.

변경 사항이 포함된 빌드가 CI 테스트를 통과하면 이를 사전 프로덕션 환경으로 안전하게 배포할 수 있습니다. 이 시점에서 시간이 오래 걸리고 많은 리소스가 투입되는 테스트를 수행할 수 있습니다.

CD 단계를 최대한 많이 자동화하면 피드백 루프가 단축되고 워크플로의 효율성이 높아집니다. 예를 들어, 테스트를 자동화하는 외에도 사전 프로덕션 환경을 새롭게 고치고 여기에 빌드를 자동으로 배포할 수 있습니다.

CI/CD를 처음 사용하는 경우, 지속적 통합과 지속적 전달 또는 배포 중에서 선택하는 데 집중하기보다는 어디서부터 시작하고 얼마나 멀리까지 갈 것인지 결정하는 것이 좋습니다.

CI 및 CD에는 모두 여러 단계가 포함되어 있으므로 진행을 점진적으로 개발할 수 있습니다.

출발점 찾기

빌드 또는 릴리스 프로세스의 일부를 이미 자동화한 경우, 또는 자동화된 테스트를 작성한 경우 이것이 자연스러운 출발점이 될 수 있습니다. 그렇지 않다면 빌드, 테스트 및 릴리스 프로세스에서 가장 시간이 걸리는 부분은 어디인지, 또는 부적합한 테스트로 프로덕션에서 문제가 발생하기 쉬운 부분은 어디인지 고려해 보세요.

조직의 다른 부문과 작업을 조율해야 할 필요성이 적고 자동화된 유닛 및 통합 테스트로 빠른 피드백을 받아 코드 품질을 쉽게 개선할 수 있다는 점에서 많은 팀이 CI로 시작합니다.

또한, CI의 이점을 인식하면 CI/CD의 효과를 높이는 자동화된 테스트를 장려하는 문화가 조성되고 자동화된 테스트의 적용 범위를 더욱 확장할 수 있습니다.

한편, 현재 릴리스 조정과 코드 개발을 모두 관리하고 있다면 우선 CD의 최종 단계(프로덕션으로 릴리스)를 자동화하여 장시간 실행에서 시간을 절약할 수 있습니다.

CI는 CD를 위한 강력한 기반을 제공하지만 지속적 전달 또는 지속적 배포의 선택은 고유한 요구 사항에 따라야 합니다. 장기적 목표가 지속적 배포일지라도 지속적 전달로 시작하는 것이 일반적인 전략입니다. 워크플로에 대한 확신이 서면 프로덕션으로의 최종 릴리스를 자동화하는 단계로 넘어갈 수 있습니다.

CI/CD 프로세스 개선

CI와 CD는 개발 작업을 작은 단위로 나누고 변경 사항을 주기적으로 커밋하는 경우에 최상의 효과를 나타냅니다.

목표가 지속적 배포인 경우, 아직 릴리스 준비가 되지 않은 기능(변경 사항이 커밋된 경우라도)을 어떻게 처리할 것인지 고려해야 합니다. 이 경우, 각 코드 변경을 자동으로 빌드하고 테스트하면서 릴리스 브랜치에서 진행 중인 작업을 분리하는 브랜치 전략, 또는 기능 플래그를 사용할 수 있습니다.

요약하자면 다음과 같습니다.

• 지속적 통합(CI)에는 자동화된 테스트를 실행하고 변경 사항을 커밋할 때마다 솔루션이 빌드되는지 확인하는 과정이 포함됩니다.
• 지속적 전달 및 지속적 배포(CD)는 모두 빌드 아티팩트를 테스트 및 스테이징 환경에 자동으로 배포하여 추가 테스트를 실행하는 과정을 거칩니다. 일반적으로 이러한 단계는 지속적 통합 이후에 수행됩니다.
  • 지속적 전달에서는 특정 빌드 아티팩트를 프로덕션으로 릴리스할 시기를 결정하고 릴리스를 수동으로 릴리스합니다.
  • 지속적 배포에서는 이전 단계를 성공적으로 통과할 때마다 코드 변경이 프로덕션으로 자동 릴리스됩니다.
• CI와 CD는 문제점을 신속하게 찾고 릴리스 전에 변경 사항에 대한 확신을 부여하도록 설계된 상호 보완적 방법입니다.
• 자동화된 테스트를 포함한 견고한 CI/CD 프로세스를 도입하면 프로덕션에 버그가 릴리스된 경우에 수정 사항을 더 빠르고 자신 있게 배포할 수 있습니다.
• 완전 자동화된 빌드, 테스트 및 릴리스 프로세스에는 CI와 CD가 모두 포함되지만, 우선 이 중에서 하나로 시작하고 프로세스를 점진적으로 키워갈 수 있습니다.
  • 자동화된 테스트는 일반적으로 개발자의 몫이기 때문에 많은 팀이 지속적 통합으로 시작합니다.
  • 하지만 릴리스 관리 책임도 맡고 있다면 우선 릴리스를 자동화하여 시간을 절약하고 CI 프로세스를 구축하는 데 집중할 수 있습니다.