웹사이트 검색

지속적인 통합, 제공 및 배포 소개


소개

소프트웨어 개발 및 릴리스는 특히 애플리케이션, 팀 및 배포 인프라가 복잡해짐에 따라 복잡한 프로세스가 될 수 있습니다. 종종 프로젝트가 성장함에 따라 문제가 더욱 두드러집니다. 빠르고 일관된 방식으로 소프트웨어를 개발, 테스트 및 릴리스하기 위해 개발자와 조직은 이러한 프로세스를 관리하고 자동화하기 위해 관련이 있지만 고유한 세 가지 전략을 만들었습니다.

지속적인 통합은 개별 개발자의 작업을 하루에 여러 번 기본 리포지토리에 통합하여 통합 버그를 조기에 파악하고 공동 개발을 가속화하는 데 중점을 둡니다. 지속적인 전달은 배포 또는 릴리스 프로세스의 마찰을 줄이고 빌드를 배포하는 데 필요한 단계를 자동화하여 언제든지 코드를 안전하게 릴리스할 수 있도록 하는 것과 관련이 있습니다. 지속적인 배포는 코드가 변경될 때마다 자동으로 배포함으로써 한 단계 더 나아갑니다.

이 가이드에서는 이러한 각 전략, 서로 어떻게 관련되어 있는지, 애플리케이션 수명 주기에 통합하여 소프트웨어 개발 및 릴리스 관행을 어떻게 변화시킬 수 있는지에 대해 설명합니다. 다양한 오픈 소스 CI/CD 프로젝트 간의 차이점을 더 잘 이해하려면 CI/CD 도구 비교를 확인하십시오.

지속적 통합이란 무엇이며 유용한 이유는 무엇입니까?

지속적 통합은 개발자가 자신의 코드를 공유 리포지토리의 기본 분기에 초기에 자주 통합하도록 권장하는 방법입니다. 개별적으로 기능을 구축하고 개발 주기가 끝날 때 기능을 통합하는 대신 각 개발자가 하루 종일 여러 번 코드를 공유 리포지토리와 통합합니다.

아이디어는 초기 고려 사항으로 만들어 통합 비용을 최소화하는 것입니다. 개발자는 새 코드와 기존 코드 사이의 경계에서 충돌을 조기에 발견할 수 있지만 충돌은 여전히 비교적 쉽게 조정할 수 있습니다. 충돌이 해결되면 새 코드가 기존 코드베이스의 요구 사항을 준수한다는 확신을 가지고 작업을 계속할 수 있습니다.

코드를 자주 통합한다고 해서 새로운 코드나 기능의 품질이 보장되는 것은 아닙니다. 많은 조직에서 코드가 표준을 충족하고 버그를 일으키지 않으며 기존 기능을 중단하지 않도록 수동 프로세스를 사용하기 때문에 통합에 비용이 많이 듭니다. 빈번한 통합은 자동화에 대한 접근 방식이 품질 보증 조치와 일치하지 않을 때 마찰을 일으킬 수 있습니다.

통합 프로세스 내에서 이러한 마찰을 해결하기 위해 실제로 지속적인 통합은 강력한 테스트 스위트와 이러한 테스트를 실행하는 자동화된 시스템에 의존합니다. 개발자가 코드를 기본 리포지토리에 병합하면 자동화된 프로세스가 새 코드 빌드를 시작합니다. 그런 다음 새 빌드에 대해 테스트 도구 모음을 실행하여 통합 문제가 발생했는지 확인합니다. 빌드 또는 테스트 단계가 실패하면 빌드를 수정하기 위해 작업할 수 있도록 팀에 경고가 표시됩니다.

지속적인 통합의 최종 목표는 통합 비용을 줄이고 결함에 조기에 대응하기 위해 일상적인 개발 워크플로의 일부인 통합을 간단하고 반복 가능한 프로세스로 만드는 것입니다. 빌드 문제에 대한 빈번한 반복 및 응답성을 장려하는 팀 문화를 조성하는 동시에 시스템이 강력하고 자동화되고 빠르도록 노력하는 것이 CI 성공의 기본입니다.

지속적 전달이란 무엇이며 왜 도움이 됩니까?

지속적 제공은 지속적 통합의 확장입니다. 팀이 언제든지 쉽고 자신 있게 프로덕션에 코드를 배포할 수 있도록 소프트웨어 제공 프로세스를 자동화하는 데 중점을 둡니다. 코드베이스가 항상 배포 가능한 상태로 유지되도록 함으로써 소프트웨어 릴리스는 복잡한 의식 없이도 별 볼 일 없는 이벤트가 됩니다. 팀은 복잡한 조정이나 후반 단계 테스트 없이 필요할 때마다 릴리스할 수 있다는 확신을 가질 수 있습니다. 지속적인 통합과 마찬가지로 지속적인 전달은 기술 및 조직 개선이 효과적이 되도록 혼합해야 하는 관행입니다.

기술 측면에서 지속적인 전달은 테스트 및 배포 프로세스를 자동화하기 위해 배포 파이프라인에 크게 의존합니다. 배포 파이프라인은 일련의 순차적 단계로 빌드에 대해 점점 더 엄격해지는 테스트 스위트를 실행하는 자동화된 시스템입니다. 이는 지속적인 통합이 중단되는 지점에서 시작되므로 신뢰할 수 있는 지속적인 통합 설정은 지속적인 제공을 구현하기 위한 전제 조건입니다.

각 단계에서 빌드는 테스트에 실패하여 팀에 경고하거나 테스트를 통과하여 다음 단계로 자동 승격됩니다. 빌드가 파이프라인을 통해 이동함에 따라 이후 단계에서는 프로덕션 환경을 최대한 가깝게 미러링하는 환경에 빌드를 배포합니다. 이러한 방식으로 빌드, 배포 프로세스 및 환경을 함께 테스트할 수 있습니다. 파이프라인은 언제든지 단일 단계로 프로덕션에 배포할 수 있는 빌드로 끝납니다.

지속적 전달의 조직적 측면은 "배포 가능성\을 주요 관심사로 우선시하도록 권장합니다. 이는 기능이 빌드되고 코드베이스의 나머지 부분에 연결되는 방식에 영향을 미칩니다. 코드 설계에 생각을 넣어야 합니다. 기능은 불완전한 경우에도 언제든지 프로덕션에 안전하게 배포할 수 있습니다. 이 영역을 지원하기 위해 여러 가지 기술이 등장했습니다.

지속적 제공은 리포지토리에 코드를 체크인하는 단계와 잘 테스트되고 기능적인 빌드를 프로덕션 인프라에 릴리스할지 여부를 결정하는 단계를 자동화하기 때문에 매력적입니다. 코드의 품질과 정확성을 주장하는 데 도움이 되는 단계는 자동화되지만 무엇을 릴리스할지에 대한 최종 결정은 최대한의 유연성을 위해 조직의 손에 맡겨집니다.

지속적 배포란 무엇이며 유용한 이유는 무엇입니까?

연속 배포는 전체 테스트 주기를 통과하는 각 빌드를 자동으로 배포하는 연속 배포의 확장입니다. 인간 게이트키퍼가 무엇을 언제 프로덕션에 배포할지 결정할 때까지 기다리는 대신 연속 배포 시스템은 배포 파이프라인을 성공적으로 통과한 모든 것을 배포합니다. 새 코드가 자동으로 배포될 때 새 기능은 나중에 또는 일부 사용자에 대해 조건부로 계속 활성화될 수 있습니다. 배포는 기능과 수정 사항을 고객에게 신속하게 자동으로 푸시하고, 제한된 범위에서 더 작은 변경을 장려하고, 현재 프로덕션에 배포된 항목에 대한 혼란을 방지하는 데 도움이 됩니다.

이 완전히 자동화된 배포 주기는 릴리스되는 항목에 대한 자동화 시스템에 대한 제어권을 포기하는 것에 대해 걱정하는 조직에게 불안의 원인이 될 수 있습니다. 자동화된 배포가 제공하는 트레이드 오프는 때때로 제공하는 보상에 비해 너무 위험한 것으로 간주됩니다.

다른 그룹에서는 이 접근 방식을 모범 사례를 항상 따르도록 하는 수단으로 활용합니다. 코드를 배포하기 전에 최종 수동 확인 없이 개발자는 코드가 잘 설계되고 테스트 스위트가 최신 상태인지 확인해야 합니다. 이를 통해 주 리포지토리에 무엇을 언제 커밋할지, 프로덕션에 무엇을 언제 릴리스할지에 대한 모든 의사 결정을 개발 팀의 단일 결정 지점으로 통합합니다.

또한 지속적인 배포를 통해 조직은 일관된 초기 피드백의 이점을 누릴 수 있습니다. 기능은 사용자에게 즉시 제공될 수 있으며 결함 또는 도움이 되지 않는 구현은 팀이 비생산적인 방향으로 많은 노력을 기울이기 전에 조기에 발견될 수 있습니다. 기능이 도움이 되지 않는다는 빠른 피드백을 받으면 팀은 영향을 최소화하는 영역에 더 많은 에너지를 투입하는 대신 초점을 이동할 수 있습니다.

연속 프로세스의 주요 개념 및 사례

지속적인 통합, 제공 및 배포는 참여 범위가 다양하지만 각각의 성공에 기본이 되는 몇 가지 개념과 사례가 있습니다.

작고 반복적인 변경

지속적인 통합을 채택할 때 가장 중요한 관행 중 하나는 작은 변화를 장려하는 것입니다. 개발자는 더 큰 작업을 작은 조각으로 나누고 조기에 커밋하는 연습을 해야 합니다. 추상화에 의한 분기 및 기능 플래그(아래 참조)와 같은 특수 기술은 진행 중인 코드 변경으로부터 기본 분기의 기능을 보호하는 데 도움이 됩니다.

작은 변경은 통합 문제의 가능성과 영향을 최소화합니다. 가능한 초기 단계에서 공유 브랜치를 커밋하고 개발 전반에 걸쳐 지속적으로 통합하면 통합 비용이 줄어들고 관련 없는 작업이 정기적으로 동기화됩니다.

트렁크 기반 개발

트렁크 기반 개발에서는 저장소의 기본 분기("트렁크\)에서 작업을 수행하거나 빈번한 간격으로 공유 저장소로 다시 병합합니다. 수명이 짧은 기능 분기는 작은 변경 사항을 나타내고 병합되는 한 허용됩니다. 가능한 한 빨리 돌아갑니다.

트렁크 기반 개발의 기본 아이디어는 위에서 논의한 작고 반복적인 변경의 개념을 위반하는 대규모 커밋을 피하는 것입니다. 범위가 작을 때 충돌을 해결할 수 있도록 동료가 코드를 조기에 사용할 수 있습니다.

릴리스는 기본 브랜치 또는 특별히 해당 목적을 위해 트렁크에서 생성된 릴리스 브랜치에서 수행됩니다. 단일 진실 소스로서 주 분기에 초점을 유지하기 위해 릴리스 분기에서 개발이 발생하지 않습니다.

구축 및 테스트 단계를 빠르게 유지

각 프로세스는 정확성을 검증하기 위해 자동화된 구축 및 테스트에 의존합니다. 빌드 및 테스트 단계를 자주 수행해야 하므로 이러한 단계에 소요되는 시간을 최소화하기 위해 이러한 프로세스를 간소화하는 것이 중요합니다.

빌드 시간의 증가는 각 커밋이 빌드를 시작한다는 사실로 인해 영향이 더해지기 때문에 주요 문제로 취급되어야 합니다. 지속적인 프로세스로 인해 개발자는 매일 이러한 활동에 참여해야 하므로 이러한 영역의 마찰을 줄이는 것은 매우 가치가 있습니다.

가능한 경우 테스트 스위트의 다른 섹션을 병렬로 실행하면 파이프라인을 통해 빌드를 더 빠르게 이동하는 데 도움이 될 수 있습니다. 테스트의 각 유형 비율이 타당한지 확인하기 위해 주의를 기울여야 합니다. 단위 테스트는 일반적으로 매우 빠르며 유지 관리 오버헤드가 최소화됩니다. 대조적으로 승인 테스트는 종종 복잡하고 파손되기 쉽습니다. 이를 설명하기 위해 단위 테스트에 크게 의존하고, 상당한 수의 통합 테스트를 수행하고, 더 복잡한 테스트의 수를 최소화하는 것이 좋습니다.

배포 파이프라인 전체의 일관성

지속적인 제공 또는 배포 구현은 릴리스 가치를 테스트하는 것으로 간주되기 때문에 프로세스의 각 단계(빌드 자체, 배포 환경 및 배포 프로세스 자체) 중에 일관성을 유지하는 것이 중요합니다.

  • 코드는 파이프라인 초기에 한 번 빌드해야 합니다. 결과 소프트웨어는 다시 빌드하지 않고 저장하고 이후 프로세스에서 액세스할 수 있어야 합니다. 각 단계에서 정확히 동일한 아티팩트를 사용하면 서로 다른 빌드 도구로 인해 불일치가 발생하지 않는다는 것을 확신할 수 있습니다.
  • 배포 환경은 일관성이 있어야 합니다. 구성 관리 시스템은 다양한 환경을 제어할 수 있으며 배포 파이프라인 자체를 통해 환경 변경 사항을 적용하여 정확성과 일관성을 보장할 수 있습니다. 레거시 조건이 테스트의 무결성을 손상시키지 않도록 테스트 주기마다 클린 배포 환경을 프로비저닝해야 합니다. 스테이징 환경은 프로덕션 환경과 최대한 일치하여 빌드가 승격될 때 존재하는 알려지지 않은 요소를 줄여야 합니다.
  • 일관된 프로세스를 사용하여 각 환경에서 빌드를 배포해야 합니다. 각 배포는 자동화되어야 하며 각 배포는 동일한 중앙 집중식 도구 및 절차를 사용해야 합니다. 파이프라인 도구로만 배포하기 위해 임시 배포를 제거해야 합니다.

배포 및 릴리스 분리

릴리스에서 사용자로의 코드 배포를 분리하는 것은 지속적 전달 및 배포의 매우 강력한 부분입니다. 코드를 처음 활성화하거나 사용자가 액세스할 수 있도록 하지 않고도 코드를 프로덕션에 배포할 수 있습니다. 그런 다음 조직은 배포와 독립적으로 새로운 기능을 출시할 시기를 결정합니다.

이는 기술 프로세스에서 비즈니스 결정을 분리하여 조직에 상당한 유연성을 제공합니다. 코드가 이미 서버에 있는 경우 배포는 더 이상 릴리스 프로세스의 민감한 부분이 아니므로 릴리스 시 참여자 수와 관련된 작업량이 최소화됩니다.

팀이 기능을 릴리스하지 않고 기능을 담당하는 코드를 배포하는 데 도움이 되는 여러 기술이 있습니다. 기능 플래그는 환경 변수의 값을 기반으로 코드를 실행할지 여부를 확인하는 조건부 논리를 설정합니다. 추상화에 의한 분기를 통해 개발자는 프로세스 입력과 출력 사이에 추상화 계층을 생성하여 점진적으로 프로세스를 재작성할 수 있습니다. 이러한 기술을 통합하기 위한 신중한 계획을 통해 이러한 두 프로세스를 분리할 수 있습니다.

테스트 유형

지속적인 통합, 제공 및 배포는 모두 자동 테스트에 크게 의존하여 각 코드 변경의 효율성과 정확성을 결정합니다. 주어진 솔루션에 대한 확신을 주장하려면 이러한 프로세스 전반에 걸쳐 다양한 유형의 테스트가 필요합니다.

아래 범주가 완전한 목록을 나타내는 것은 아니며 각 유형의 정확한 정의에 대해 의견이 일치하지 않지만 이러한 광범위한 테스트 범주는 다양한 컨텍스트에서 코드를 평가하는 다양한 방법을 나타냅니다.

연기 테스트

스모크 테스트는 일부 기본 구현 및 환경 가정뿐만 아니라 핵심 기능을 보장하기 위해 고안된 특별한 종류의 초기 검사입니다. 스모크 테스트는 일반적으로 더 완전한 테스트 스위트를 실행하기 전에 온전성 검사로 각 테스트 주기의 맨 처음에 실행됩니다.

이러한 유형의 테스트 이면에 있는 아이디어는 구현에서 큰 위험 신호를 포착하고 추가 테스트가 불가능하거나 가치가 없음을 나타낼 수 있는 문제에 주의를 기울이도록 돕는 것입니다. 스모크 테스트는 매우 광범위하지는 않지만 매우 신속해야 합니다. 변경 사항이 스모크 테스트에 실패하면 핵심 어설션이 손상되었으며 문제가 해결될 때까지 테스트에 더 이상 시간을 할애해서는 안 된다는 초기 신호입니다.

상황별 스모크 테스트는 기본 가정 및 요구 사항이 충족되었는지 확인하기 위해 새로운 단계 테스트를 시작할 때 사용할 수 있습니다. 예를 들어 스모크 테스트는 통합 테스트 또는 스테이징 서버에 배포하기 전에 모두 사용할 수 있지만 테스트할 조건은 경우에 따라 다릅니다.

단위 테스트

단위 테스트는 코드의 개별 요소를 격리되고 고도로 타겟팅된 방식으로 테스트하는 역할을 합니다. 개별 함수 및 클래스의 기능은 자체적으로 테스트됩니다. 모든 외부 종속성은 스텁 또는 모의 구현으로 대체되어 문제의 코드에 테스트를 완전히 집중시킵니다.

단위 테스트는 더 복잡한 컨텍스트에 배치되기 전에 내부 일관성 및 정확성을 위해 개별 코드 구성 요소의 정확성을 테스트하는 데 필수적입니다. 제한된 테스트 범위와 종속성 제거로 인해 결함의 원인을 쉽게 찾을 수 있습니다. 또한 나중에 재현하기 어려울 수 있는 다양한 입력 및 코드 분기를 테스트하기에 가장 좋은 시기입니다. 종종 스모크 테스트 후에 변경 사항이 있을 때 실행되는 첫 번째 테스트는 단위 테스트입니다.

단위 테스트는 일반적으로 변경 사항을 제출하기 전에 개별 개발자가 자신의 워크스테이션에서 실행합니다. 그러나 지속적 통합 서버는 거의 항상 통합 테스트를 시작하기 전에 보호 조치로 이러한 테스트를 다시 실행합니다.

통합 테스팅

단위 테스트 후 구성 요소를 함께 그룹화하고 어셈블리로 테스트하여 통합 테스트를 수행합니다. 단위 테스트는 코드의 기능을 개별적으로 검증하는 반면 통합 테스트는 구성 요소가 서로 상호 작용할 때 협력하는지 확인합니다. 이러한 유형의 테스트는 구성 요소 간의 상호 작용을 통해 노출되는 완전히 다른 클래스의 버그를 포착할 수 있는 기회가 있습니다.

일반적으로 통합 테스트는 코드가 공유 저장소에 체크인될 때 자동으로 수행됩니다. 지속적 통합 서버는 코드를 확인하고 필요한 빌드 단계를 수행한 다음(일반적으로 빌드가 성공했는지 확인하기 위해 빠른 스모크 테스트 수행) 단위 및 통합 테스트를 실행합니다. 모듈은 서로 다른 조합으로 연결되어 테스트됩니다.

통합 테스트는 프로젝트의 상태를 보호하기 때문에 공유 작업에 중요합니다. 변경 사항은 기존 기능을 중단하지 않고 예상대로 다른 코드와 상호 작용한다는 것을 증명해야 합니다. 통합 테스트의 두 번째 목표는 변경 사항을 깨끗한 환경에 배포할 수 있는지 확인하는 것입니다. 이것은 종종 개발자 자신의 컴퓨터에서 수행되지 않는 첫 번째 테스트 주기이므로 이 프로세스 중에 알 수 없는 소프트웨어 및 환경 종속성도 발견될 수 있습니다. 일반적으로 새 코드가 실제 외부 라이브러리, 서비스 및 데이터에 대해 테스트되는 첫 번째 시간이기도 합니다.

시스템 테스트

통합 테스트가 수행되면 시스템 테스트라는 또 다른 수준의 테스트를 시작할 수 있습니다. 여러 면에서 시스템 테스트는 통합 테스트의 확장 역할을 합니다. 시스템 테스트의 초점은 구성 요소 그룹이 응집력 있는 전체로서 올바르게 작동하는지 확인하는 것입니다.

구성 요소 간의 인터페이스에 초점을 맞추는 대신 시스템 테스트는 일반적으로 전체 소프트웨어의 외부 기능을 평가합니다. 이 테스트 세트는 구성된 소프트웨어를 통합된 엔티티로 측정하기 위해 구성 요소를 무시합니다. 이러한 구분으로 인해 시스템 테스트는 일반적으로 사용자 또는 외부에서 액세스할 수 있는 인터페이스에 중점을 둡니다.

수락 테스트

승인 테스트는 배송 전에 소프트웨어에서 수행되는 마지막 유형의 테스트 중 하나입니다. 수락 테스트는 소프트웨어가 비즈니스 또는 사용자 관점에서 모든 요구 사항을 충족하는지 여부를 결정하는 데 사용됩니다. 이러한 테스트는 때때로 원래 사양에 대해 구축되며 일부 예상 기능 및 유용성에 대한 인터페이스를 테스트하는 경우가 많습니다.

승인 테스트는 종종 소프트웨어 릴리스를 지나서 확장될 수 있는 보다 복잡한 단계입니다. 자동화된 수락 테스트를 사용하여 설계의 기술적 요구 사항이 충족되었는지 확인할 수 있지만 일반적으로 수동 검증도 중요한 역할을 합니다.

종종 수락 테스트는 프로덕션 시스템을 미러링하는 스테이징 환경에 빌드를 배포하는 것으로 시작됩니다. 여기에서 자동화된 테스트 스위트를 실행할 수 있고 내부 사용자는 시스템에 액세스하여 필요한 방식으로 작동하는지 확인할 수 있습니다. 소프트웨어를 출시하거나 사용자에게 베타 액세스 권한을 제공한 후 실제 사용 시 소프트웨어 기능을 평가하고 추가 피드백을 수집하여 추가 승인 테스트를 수행합니다.

추가 용어

위에서 광범위한 개념에 대해 논의했지만 지속적인 통합, 제공 및 배포에 대해 배우면서 접할 수 있는 많은 관련 개념이 있습니다. 볼 가능성이 있는 몇 가지 다른 용어를 정의해 보겠습니다.

  • 블루-그린 배포: 블루-그린 배포는 프로덕션과 유사한 환경에서 코드를 테스트하고 다운타임을 최소화하면서 코드를 배포하기 위한 전략입니다. 프로덕션 가능 환경의 두 세트가 유지 관리되고 테스트가 발생할 수 있는 비활성 세트에 코드가 배포됩니다. 출시 준비가 되면 프로덕션 트래픽이 새 코드와 함께 서버로 라우팅되어 변경 사항을 즉시 사용할 수 있습니다.
  • 추상화에 의한 분기: 추상화에 의한 분기는 소스 코드 리포지토리에서 오래 지속되는 개발 분기 없이 활성 프로젝트에서 주요 리팩토링 작업을 수행하는 방법으로, 지속적인 통합 관행이 권장되지 않습니다. 추상화 계층은 기존 구현 내에서 구축 및 배포되므로 새 구현이 추상화 뒤에 병렬로 구축될 수 있습니다.
  • 빌드(명사): 빌드는 소스 코드에서 생성된 소프트웨어의 특정 버전입니다. 언어에 따라 컴파일된 코드 또는 해석된 코드의 일관된 번들일 수 있습니다.
  • 카나리아 릴리스: 카나리아 릴리스는 제한된 사용자 하위 집합에 대한 변경 사항을 릴리스하기 위한 전략입니다. 아이디어는 문제가 있는 경우 영향을 최소화하면서 프로덕션 워크로드에서 모든 것이 올바르게 작동하는지 확인하는 것입니다.
  • 다크 런칭: 다크 런칭은 프로덕션 트래픽을 수신하지만 사용자 경험에 영향을 미치지 않는 프로덕션에 코드를 배포하는 관행입니다. 새로운 변경 사항은 기존 구현과 함께 배포되며 테스트를 위해 동일한 트래픽이 두 위치로 라우팅되는 경우가 많습니다. 이전 구현은 여전히 사용자 인터페이스에 연결되어 있지만 뒤에서 프로덕션 환경에서 실제 사용자 요청을 사용하여 새 코드의 정확성을 평가할 수 있습니다.
  • 배포 파이프라인: 배포 파이프라인은 점점 더 엄격해지는 테스트 및 배포 시나리오를 통해 소프트웨어를 이동하여 릴리스 준비 상태를 평가하는 구성 요소 집합입니다. 파이프라인은 일반적으로 프로덕션에 자동으로 배포하거나 수동으로 배포할 수 있는 옵션을 제공하여 끝납니다.
  • 기능 플래그 또는 기능 토글: 기능 플래그는 환경 변수의 값을 기반으로 실행할지 여부를 결정하는 조건 논리 뒤에 새 기능을 배포하는 기술입니다. 이 플래그를 적절하게 설정하여 새 코드를 활성화하지 않고 프로덕션에 배포할 수 있습니다. 기능 플래그에는 종종 일부 사용자가 새 기능에 액세스할 수 있도록 허용하는 논리가 포함되어 있어 새 코드를 점진적으로 출시하는 메커니즘을 생성합니다.
  • 승격: 지속적인 프로세스의 맥락에서 승격은 소프트웨어 빌드를 다음 테스트 단계로 이동하는 것을 의미합니다.
  • 소크 테스트: 소크 테스트는 오랜 기간 동안 상당한 생산 또는 생산과 같은 부하에서 소프트웨어를 테스트하는 것입니다.

결론

이 가이드에서는 지속적 통합, 지속적 제공 및 지속적 배포를 소개하고 잘 테스트된 소프트웨어를 안전하고 신속하게 빌드하고 릴리스하는 데 사용할 수 있는 방법에 대해 설명했습니다. 이러한 프로세스는 광범위한 자동화를 활용하고 지속적인 코드 공유를 장려하여 결함을 조기에 수정합니다. 이러한 솔루션을 구현하는 데 필요한 기술, 프로세스 및 도구는 상당한 투자를 나타내지만 잘 설계되고 적절하게 사용되는 시스템의 이점은 막대할 수 있습니다.

프로젝트에 적합한 CI/CD 솔루션을 찾으려면 CI/CD 도구 비교 가이드에서 자세한 정보를 확인하세요.