우리 팀은 현재 다음과 같은 상당히 간단한 분기 / 배치 프로세스를 사용합니다.
┌────────┐ ┌────┐ ┌──────┐
Environments: │ DEV │ │ QA │ │ PROD │
└────────┘ └────┘ └──────┘
▲ ▲ ▲
│ │ │
┌────────┐ ┌────┐ ┌──────┐
Builds: │ DEV │ │ QA │ │ PROD │
└────────┘ └────┘ └──────┘
▲ ▲ ▲
│ │ │
┌────────┐ ┌────┐ ┌──────┐
Branches: │ master │ │ qa │ │ prod │
└────────┘ └────┘ └──────┘
각 환경에는 자체 분기 ( git 사용 )와 해당 분기를 사용하는 자체 빌드가 있습니다. 한 환경에서 다른 환경으로 (예 : DEV에서 QA로) 홍보하려는 경우 master지점을 병합하고 qa새 QA 빌드 (QA 환경에 자동으로 배포)를 시작합니다.
우리는 전용 브랜치를 가지지 않고 각 환경에 맞게 구축하는 새로운 프로세스로의 전환을 고려하고 있습니다. 대신, 단일 릴리스 빌드는 "배포 패키지"를 생성 한 다음 모든 환경에 배포 할 수 있습니다. 우리는 일반적인 워크 플로가 다음과 같이 보일 것이라고 상상하고 있습니다.
┌────────┐ ┌────┐ ┌──────┐
Environments: │ DEV │ ──► │ QA │ ──► │ PROD │
└────────┘ └────┘ └──────┘
▲
\
┌───────────────┐
Builds: │ release build │
└───────────────┘
▲
│
┌────────┐ ┌─────────┐
Branches: │ master │ │ release │
└────────┘ └─────────┘
한 환경에서 다른 환경으로의 승격은 더 이상 소스 제어에서 처리되지 않습니다. 오히려 이미 구축 된 바이너리 ( "배포 패키지")를 가져 와서 새로운 환경에 드롭합니다.
이 새로운 시스템을 사용하면 모든 환경에 빌드를 배포 할 수 있으며 몇 가지 장점이 있습니다. 예를 들어, DEV 및 QA에서 PROD 버그 수정을 테스트하는 것은 쉽지 않습니다. 현재 시스템은 브랜치를 롤백하지 않고 쉽게 할 수있는 방법을 제공하지 않습니다. 우리는 분명히 피하고 싶습니다.
이 새로운 시스템의 가장 큰 단점은 더 이상 어떤 환경에 어떤 코드가 있는지 추적하는 자동 방법이 없다는 것입니다. PROD에서 수정해야 할 경우 더 이상 현재 프로덕션 코드베이스와 동기화되는 전용 분기가 없습니다. QA도 마찬가지입니다. 진행중인 작업을 방해하지 않고 QA로 빠른 변경 사항을 적용하려는 경우 master더 이상 QA 환경의 현재 상태를 반영하는 지점이 없습니다.
각 환경에 어떤 코드가 있는지 어떻게 추적 할 수 있습니까?
고려중인 몇 가지 옵션 :
- 어떤 커밋이 어떤 환경에 있는지 추적하기 위해 git 태그 를 사용
- 빌드에서 사용하는 git commit을 각 배포 패키지에 포함