지속적인 통합 vs 지속적인 전달 vs 지속적인 배포
소프트웨어 개발에서 프로세스는 지속적인 통합으로 시작한 다음 지속적인 배포가 이 프로세스를 기반으로 지속적인 통합 중에 공유 트렁크에 병합된 변경 사항을 릴리스합니다. 즉, 지속적인 배포는 개발 단계에서 프로덕션 단계까지 코드를 자동으로 배포할 수 있음을 의미합니다.
따라서 CI/CD는 새로운 릴리스를 지속적으로 개발하고 테스트하고 제공하는 프로세스를 의미합니다.
지속적인 배포는 종종 지속적인 배포와 혼동되지만, 실제로는 지속적인 배포보다 한 단계 더 나아갑니다.
이 단계에서는 모든 변경 사항이 인간의 개입 없이 자동으로 릴리스되는 반면, 지속적인 배포에서는 변경 사항이 배포를 위해 준비되지만 릴리스 시기는 팀에서 수동으로 결정합니다.
즉, 지속적인 배포는 부분적으로 수동 프로세스인 반면 지속적인 배포는 전체 릴리스 프로세스를 자동화하는 것입니다. 이 단계에서 자동화된 테스트가 실패하면 변경 사항이 릴리스되지 않지만 변경 사항이 테스트를 통과하면 자동으로 배포됩니다.
따라서 지속적인 배포는 최종 사용자와의 피드백 루프를 가속화하는 효율적인 수단입니다.
이 세 가지 주요 개념을 요약하면 다음과 같습니다.
- CI(지속적인 통합) – 하루에 여러 번 공유 트렁크에 병합되는 단기 브랜치로, 자동화된 일련의 테스트를 통해 적용된 변경 사항에 대한 피드백을 제공합니다.
- 지속적인 배포(CD) – 지속적인 통합 후 지속적인 배포는 소프트웨어를 배포할 준비를 합니다. 프로덕션에 대한 배포는 일반적으로 수동입니다.
- 지속적인 배포 – CI 및 CD 이후, 변경 사항은 자동으로 프로덕션에 배포됩니다. 완전 자동화된 프로세스입니다.
그러나 이 모든 과정은 서로 연계되어야 하며, 지속적인 통합은 다른 두 과정이 일어나기 위한 기반이 됩니다.
지속적인 테스트
CI/CD 동안 소프트웨어는 일련의 자동화된 테스트를 거칩니다. 따라서 CI/CD 프로세스에는 다음과 같은 유형의 테스트가 포함될 수 있습니다.
- 단위 테스트 – 애플리케이션의 단일 부분을 검증합니다. 코드 베이스의 이 격리된 부분을 단위라고 합니다.
- 통합 테스트 – 단위 테스트는 개별 구성 요소에 초점을 맞추기 때문에 그 자체로는 충분하지 않을 수 있으므로, 통합 테스트는 여러 구성 요소가 올바르게 함께 작동하는지 확인하고 애플리케이션의 각 부분이 전체적으로 어떻게 함께 작동하는지 테스트합니다.
- 기능 테스트 – 이 테스트는 기능이 제대로 작동하는지 확인합니다.
- 종단 간 테스트 – 이러한 테스트는 실제 사용자가 원활하고 버그 없는 경험을 하는지 확인하기 위해 사용자 경험을 시뮬레이션합니다.
- 수용 테스트 – 이는 상당한 부하 하에서 소프트웨어의 동작을 검증하여 안정성과 신뢰성을 보장합니다.
아래 테스트 피라미드는 실행할 수 있는 다양한 유형의 테스트를 보여줍니다. 어떤 경우에는, 특히 방금 시작한 경우, 이 모든 테스트를 실행할 필요가 없을 수도 있습니다.
단위 테스트는 구현하기 가장 쉽고 리소스가 적게 필요하므로 일반적으로 빠른 빌드를 위한 좋은 기반을 마련하고 개발자에게 훨씬 더 빠르게 피드백을 제공합니다. 한편, 사용자 관점에서 애플리케이션이 올바르게 작동하는지 확인하는 UI 테스트는 훨씬 느리고 실행하기가 더 복잡합니다. 요약하자면 모든 CI/CD 프로세스에 이러한 모든 테스트가 있는 것은 아니지만 자동화를 통한 지속적인 테스트는 지속적인 통합 및 지속적인 제공의 핵심 구성 요소라는 점을 기억하는 것이 좋습니다.
CI/CD 파이프라인이란 무엇인가요?
CI/CD 파이프라인은 소스코드를 프로덕션 단계까지 소프트웨어의 제공 라이프사이클을 추적하는 일련의 자동화된 테스트입니다.
따라서 일반적인 파이프라인은 코드를 빌드하고, 테스트를 실행한 다음 소프트웨어 개발 라이프사이클을 정확히 복제하여 새 소프트웨어를 프로덕션에 배포합니다.
CI/CD 파이프라인을 통합하는 것은 최소한의 위험으로 소프트웨어를 빠르고 효율적으로 릴리스할 수 있기 때문에 DevOps 문화를 유지하는 데 필수적인 요소입니다. 따라서 CI/CD 파이프라인을 구축하면 DevOps 이상을 실현할 수 있으며, 개발자는 변경 사항을 자주 커밋하여 빠른 피드백을 얻을 수 있으므로 팀 간의 협업 문화, 생산성 증가 및 투명성이 생겨납니다. 이러한 빠른 피드백 루프는 효율적인 CI/CD 파이프라인을 구축하는 데 필요한 주요 목표를 달성하는 데 도움이 되며, 이는 일반적으로 새 릴리스와 관련된 위험을 줄이는 것입니다.
따라서 이러한 파이프라인에는 다음과 같은 요소가 포함됩니다.
- 코드 연속 통합을 빌드, 병합한 다음 테스트
- 배달을 위한 코드 준비 – 지속적인 배달
- 코드를 자동으로 배포 – 지속적인 배포
다음 이미지는 일반적인 CI/CD 파이프라인 단계의 예를 보여줍니다.
따라서 CI/CD 파이프라인의 단계는 다음과 같다고 추론할 수 있습니다.
- 소스: CI/CD 파이프라인은 새 코드가 저장소에 커밋되면 트리거됩니다.
- 빌드: 개발자가 새로운 코드 변경 사항을 넣고 이를 컴파일하여 초기 테스트 단계를 통과할 수 있도록 하는 곳입니다.
- 테스트: 이는 자동화된 테스트를 통해 새 코드를 테스트하는 경우입니다(예: 연속 통합을 통한 단위 테스트 실행). 소프트웨어의 크기와 복잡성에 따라 이 단계는 몇 초에서 몇 시간까지 걸릴 수 있습니다. 이 단계는 개발자가 문제를 해결하는 데 필요한 피드백을 제공합니다.
- 배포: 이는 최종 릴리스를 준비하기 위해 코드가 테스트 또는 스테이징 환경에 배포되는 경우입니다. 즉, 지속적인 배포입니다. 일반적으로 빌드는 일련의 자동화된 테스트를 거치면 자동으로 배포됩니다.
- 프로덕션에 배포: 여기서 코드는 수동 또는 자동으로 최종 사용자에게 도달하기 위해 라이브 프로덕션 환경에 릴리스됩니다.
현대 소프트웨어 개발팀에서 이러한 파이프라인을 갖는 것은 중요합니다. 이러한 프로세스를 통해 팀은 더 지루한 작업을 자동화하는 동안 코드 작성과 제품 개선에 에너지와 시간을 쏟을 수 있습니다.
이는 자동화를 도입하여 수동 프로세스를 줄이는 진정한 DevOps 문화의 이면에 있는 아이디어와 관련이 있습니다. CI/CD가 없다면 변경 사항을 통합한 다음 테스트하고 배포하려면 상당한 시간과 노력이 필요한 별도의 프로세스가 필요합니다.
이처럼 자동화된 프로세스를 통해 소프트웨어 개발 수명 주기 전반에 걸쳐 오류가 줄어들고 협업과 효율성이 향상됩니다.
실제로 CI/CD 파이프라인을 구현하면 개발, IT, 운영 팀이 협력하여 더 높은 품질의 소프트웨어를 더 자주 제공할 수 있으므로 협업 환경이 조성됩니다.
CI/CD 모범 사례
효율적인 CI/CD 파이프라인을 위한 모범 사례는 다음과 같습니다.
1. 일찍 그리고 자주 약속하세요
2. 프로덕션에 배포하는 유일한 방법으로 만드십시오.
3. 자동화 프로세스를 지속적으로 검토하세요
4. 파이프라인을 가속화하세요
5. 파이프라인을 모니터링하세요
효율적인 파이프라인을 설계하기 위한 CI/CD 도구
CI/CD는 팀이 개발, 테스트 및 배포 프로세스를 자동화하는 데 도움이 될 수 있습니다. 일부 도구는 지속적인 통합 측면을 처리하는 데 중점을 두지만 다른 도구는 지속적인 배포에 더 중점을 둡니다.
이 섹션에서는 이러한 프로세스를 자동화하는 데 사용되는 일반적인 도구 중 일부를 강조하겠습니다. 조직에 가장 적합한 효율적인 CI/CD 파이프라인을 구현하려면 올바른 도구를 선택하는 것이 중요합니다.
널리 사용되는 도구는 다음과 같습니다.
- Jenkins: CI/CD를 위한 가장 잘 알려진 오픈소스 도구 중 하나입니다. 확장 가능한 자동화 서버로서 CI 서버로 사용할 수 있으며 지속적인 배포 허브로 전환할 수 있습니다.
- CircleCI: 유연한 환경과 수천 개의 사전 구축된 통합을 제공하는 도구입니다. 클라우드에서 CI/CD 오케스트레이션을 제공하거나, 유연성과 제어력을 높이기 위해 셀프 호스팅 러너를 사용할 수 있는 옵션이 제공됩니다.
- GitLab CI/CD: 이 도구를 사용하면 릴리스 프로세스를 간소화하고 자동화하여 안전하고 유연한 배포 옵션을 제공할 수 있습니다. GitLab은 또한 CI/CD의 단일 진실 소스 역할을 하므로 단일 애플리케이션에서 코드를 빌드, 테스트, 배포 및 모니터링할 수 있습니다.
- Travis CI: 이것은 개발자가 코드를 빠르고 쉽게 개발, 테스트 및 배포할 수 있도록 돕는 오픈소스 CI/CD 플랫폼입니다. 이 도구는 빠르게 설정되고 30개 이상의 언어를 지원하여 뛰어난 유연성을 제공합니다.
- 세마포어: 이 도구는 iOS 앱을 포함한 여러 언어와 플랫폼을 지원합니다. 따라서 릴리스를 가속화하고 웹, 데스크톱 및 모바일 앱에 배포하는 데 사용할 수 있습니다.
- Spinnaker: 다양한 클라우드 공급업체와 협력하여 빠르고 안전하며 반복 가능한 배포를 제공하는 오픈소스 지속적 배포 플랫폼입니다.
CI/CD + 기능 플래그: 더욱 빠른 배포를 위한 마법의 공식
살펴본 것처럼 지속적인 통합과 지속적인 제공은 고품질 소프트웨어를 더 빠르게 제공하는 데 도움이 되는 두 가지 필수적인 관행입니다.
이러한 프로세스에 기능 플래그를 구현하면 새로운 변경 사항을 통합하고 배포할 때 더 많은 가치를 제공하고 위험을 줄일 수 있습니다.
기능 플래그란 무엇인가요?
기능 플래그는 코드 배포와 기능 릴리스를 분리하여 프로덕션에서 안전하게 테스트하기 위해 특정 기능을 켜거나 끄는 것을 목적으로 하는 소프트웨어 개발 도구입니다.
다음과 같은 시나리오를 상상해 보세요. 여러 개발자가 다양한 타임라인에 걸쳐 여러 변경 작업을 진행하고 있습니다.
변경 사항을 완료한 개발자가 있는 반면 다른 개발자는 아직 완료하지 않은 경우 어떻게 되나요? 이전에는 개발자가 팀의 모든 사람이 변경 사항을 완료할 때까지 기다려야 변경 사항을 최종적으로 통합하고 배포할 수 있었습니다.
이로 인해 새로운 릴리스가 출시될 때까지 더 오랜 시간 기다려야 하는 고객 불만이 발생할 수 있으며, 변경 사항이 충분히 자주 병합되지 않아 피드백 루프가 중단될 수 있습니다.
기능 플래그를 사용하면 개발자는 다른 개발자가 완료될 때까지 기다리지 않고도 코드에서 완료되지 않은 부분을 간단히 꺼서 변경 사항을 푸시할 수 있습니다.
즉, 이러한 미완료 변경 사항은 기능 플래그 뒤에 숨길 수 있고, 완료된 변경 사항은 릴리스될 수 있습니다. 완료되면 최종 사용자에게 표시되도록 켤 수 있습니다.
이것이 중요한 이유는 지속적인 통합의 전반적인 목적이 하루에 한 번 이상 변경 사항을 통합하는 것이기 때문이며, 따라서 기능 플래그는 지속적인 통합의 모멘텀을 유지하는 데 도움이 됩니다.
이와 비슷한 방식으로, 기능 플래그는 개발자가 플래그 뒤에 미완료 변경 사항을 숨겨 사용자 경험에 영향을 미치지 않으면서도 릴리스를 진행할 수 있으므로 지속적인 제공에 대한 약속을 지키는 데 도움이 됩니다.
이를 통해 제품 출시 시간이 단축될 뿐만 아니라 지속적인 피드백을 수집하여 제품을 개선하고 결과적으로 고객 만족도가 향상됩니다.
기능 플래그는 킬 스위치로도 유용합니다. 즉, 버그가 자동화된 테스트를 통과하면 기능 플래그를 사용하여 쉽게 끄거나 롤백할 수 있습니다. 이렇게 하면 버그가 있는 기능을 비활성화할 수 있고 전체 기능 릴리스는 비활성화할 수 없습니다.
여기서 가장 중요한 점은 기능 플래그를 사용하면 최종 사용자에게 더 빠르고 안전하게 릴리스를 제공할 수 있다는 것입니다.