기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

전체 CI/CD 프로세스가 어떻게 다른지

CI/CD 파이프라인은 개발자가 CI/CD 파이프라인의 CD 부분을 통해 빌드되고 테스트되는 기본 브랜치(또는 트렁크)에 작고 빈번한 업데이트를 병합하는 최신 트렁크 기반 워크플로를 사용합니다. 이 워크플로는 개발 및 릴리스 브랜치가 릴리스 일정으로 구분되는 Gitflow 워크플로를 대체했습니다. 많은 조직에서 Gitflow는 여전히 버전 관리 및 배포의 인기 있는 방법입니다. 그러나 이제 레거시로 간주되므로 CI/CD 파이프라인에 통합하는 것이 어려울 수 있습니다.

많은 조직의 경우 Gitflow 워크플로에서 트렁크 기반 워크플로로 전환하는 작업이 완료되지 않았으며, 그 결과 어딘가에 멈춰 CI/CD로 완전히 마이그레이션되지 않습니다. 하지만 파이프라인은 과거와 현재 사이에 전환 상태로 멈춰 레거시 워크플로의 특정 잔물에 달라붙습니다. Git 워크플로의 차이점을 검토한 다음 레거시 워크플로를 사용하는 것이 다음에 어떤 영향을 미칠 수 있는지 알아봅니다.

최신 구성에서 레거시 Git 워크플로의 잔고를 더 쉽게 식별할 수 있도록 Gitflow를 최신 트렁크 기반 접근 방식과 비교해 보겠습니다.

Gitflow 접근 방식

다음 이미지는 Gitflow 워크플로를 보여줍니다. Gitflow 접근 방식은 여러 브랜치를 사용하여 여러 가지 코드 버전을 동시에 추적합니다. 개발자가 코드의 현재 버전에서 작업하는 동안 향후 일정 기간 동안 애플리케이션에 대한 업데이트 릴리스를 예약합니다. 트렁크 기반 리포지토리는 기능 플래그를 사용하여 이를 수행할 수 있지만 기본적으로 Gitflow에 내장되어 있습니다.

Gitflow 접근 방식의 한 가지 결과는 애플리케이션 환경이 일반적으로 동기화되지 않는다는 것입니다. 표준 Gitflow 구현에서 개발 환경은 코드의 현재 상태를 반영하는 반면, 사전 프로덕션 및 프로덕션 환경은 최신 릴리스의 코드 기반 상태에 고정되어 있습니다.

이렇게 하면 개발자가 작업하는 코드 베이스가 릴리스되지 않은 기능을 노출하지 않고는 프로덕션 환경에 결함이 나타날 때 작업이 복잡해집니다. Gitflow가이 상황을 처리하는 방법은 핫픽스를 사용하는 것입니다. 핫픽스 브랜치는 릴리스 브랜치에서 생성된 다음 상단 환경에 직접 배포됩니다. 그런 다음 핫픽스 브랜치는 코드를 최신 상태로 유지하기 위해 개발 브랜치에 병합됩니다.

트렁크 기반 접근 방식

다음 이미지는 트렁크 기반 워크플로를 보여줍니다. 트렁크 기반 워크플로에서 개발자는 기능 브랜치에서 로컬로 기능을 빌드 및 테스트한 다음 이러한 변경 사항을 기본 브랜치에 병합합니다. 이후 기본 브랜치는 개발, 프로덕션 이전 및 프로덕션 환경에 순차적으로 구축됩니다. 단위 및 통합 테스트는 각 환경 간에 수행됩니다.

이 워크플로를 사용하면 모든 환경이 동일한 코드 기반을 운영합니다. 릴리스되지 않은 기능을 노출하지 않고도 기본 브랜치에서 변경 사항을 구현할 수 있으므로 상위 환경에 핫픽스 브랜치가 필요하지 않습니다. 기본 브랜치는 항상 안정적이고 결함이 없으며 릴리스 준비가 된 것으로 간주됩니다. 이를 통해 CI/CD 파이프라인의 소스로 통합할 수 있습니다.이 파이프라인은 파이프라인의 모든 환경을 통해 코드 기반을 자동으로 테스트하고 배포할 수 있습니다.