이 기사에서는 트렁크 기반 개발 및 환경 기반 기능 플래그를 중심으로 구축된 웹 애플리케이션을 위한 강력하고 효율적인 릴리스 프로세스를 간략하게 설명합니다. 이 방법론은 고품질 표준을 유지하면서 지속적인 통합, 손쉬운 프로덕션 테스트, 개발에서 릴리스까지의 원활한 경로를 보장합니다.
핵심 원칙
-
트렁크 기반 개발:
- 트렁크 브랜치는 모든 개발 작업에 대한 단일 정보 소스 역할을 합니다.
- 개발자는 새로운 기능이나 Jira 티켓을 위해 트렁크에서 기능 브랜치(예: feature/xyz)를 생성합니다.
- 풀 요청(PR)은 성공적인 테스트 후 검토 및 병합을 위해 이러한 기능 브랜치에서 트렁크로 제출됩니다.
-
환경 기반 기능 플래그:
- 기능 플래그는 환경 전반에 걸쳐 기능 활성화를 제어하는 데 사용됩니다.
- 플래그는 환경별 구성 파일에 저장되거나 CI/CD 파이프라인 구성의 일부로 저장됩니다.
- Trunk 브랜치에서는 기본적으로 모든 기능 플래그가 OFF로 설정되어 있습니다.
- 필요에 따라 특정 환경(예: 샌드박스, 스테이징 또는 프로덕션)에서 플래그를 ON 토글할 수 있습니다.
Sprint의 JIRA 버전
환경 배포 흐름
-
샌드박스 또는 스테이징 환경:
- QA 및 통합 테스트를 위해 팀은 트렁크에서 sandbox/(예: sandbox/xyz) 접두사가 붙은 분기를 생성할 수 있습니다.
- 이 브랜치는 CI/CD 파이프라인을 사용하여 전용 샌드박스 또는 스테이징 환경에 배포됩니다.
- QA 팀은 새로운 기능을 검증할 수 있으며 통합 테스트는 호환성을 보장할 수 있습니다.
- 이 환경에서는 특정 기능을 테스트하기 위해 기능 플래그가 켜짐 전환됩니다.
-
제품 출시 준비:
- 릴리스를 준비하려면 트렁크에서 release/xyz 브랜치를 생성하세요.
- release/xyz 분기는 릴리스 후보 역할을 하며 처음에는 베타 테스트를 위해 프로덕션 트래픽의 5%에 배포됩니다.
- 새로운 기능에 대한 기능 플래그는 프로덕션 환경에서 테스트할 수 있도록 이 분기에서 ON으로 전환됩니다.
- Nginx 또는 유사한 로드 밸런서는 이러한 트래픽 분할을 처리하여 일부 사용자에게만 변경 사항이 표시되도록 할 수 있습니다.
기능 플래그: 예 및 사용법
-
플래그 구조:
- 구성 파일(예: config/feature-flags.json)에 기능 플래그를 저장합니다.
{
"feature_xyz": false,
"feature_abc": true
}
-
백엔드 예:
const featureFlags = require('./config/feature-flags');
if (featureFlags.feature_xyz) {
console.log('Feature XYZ is enabled!');
} else {
console.log('Feature XYZ is disabled.');
}
-
프런트엔드 예:
- 플래그를 사용하여 UI 구성요소를 조건부로 렌더링합니다.
if (process.env.REACT_APP_FEATURE_XYZ === 'true') {
render(<NewFeatureComponent />);
} else {
render(<OldFeatureComponent />);
}
-
테스트 중 플래그 전환:
- 테스트용 플래그를 전환하려면 구성 또는 환경 변수를 업데이트하고 관련 서비스(프런트엔드 또는 백엔드)를 다시 시작하세요.
FEATURE_XYZ=true npm start
- CI/CD 파이프라인의 경우 배포 중에 적절한 플래그 값이 환경에 삽입되었는지 확인하세요.
프로덕션 테스트
-
베타 테스트를 위한 트래픽 라우팅:
- Nginx 구성을 사용하여 트래픽 할당을 제어합니다.
http {
upstream stable_backend {
server stable_backend_1;
server stable_backend_2;
}
upstream canary_backend {
server canary_backend_1;
server canary_backend_2;
}
upstream mixed_backend {
server stable_backend_1 weight=45;
server stable_backend_2 weight=45;
server canary_backend_1 weight=5;
server canary_backend_2 weight=5;
}
server {
listen 80;
server_name my-app.example.com;
location / {
if ($http_x_qa_test = "true") {
proxy_pass http://canary_backend;
break;
}
proxy_pass http://mixed_backend;
}
}
}
- 로드 밸런서 가중치를 조정하여 프로덕션 트래픽의 5%를 새 버전을 실행하는 서버로 라우팅합니다.
-
프로덕션 전용 QA 테스트:
- QA 팀은 요청에 맞춤 쿠키(예: qa-test=true)를 첨부할 수 있습니다.
- Nginx는 이 쿠키를 확인하고 이러한 요청을 100% 새 버전으로 라우팅하여 프로덕션에서 타겟 테스트를 보장합니다.
출시 안정화
-
문제 해결:
- 개발자는 트렁크 브랜치에 PR을 열어 베타 테스트 중에 확인된 문제를 해결합니다.
- 병합된 후에는 이러한 수정 사항이 release/xyz 브랜치에 선별적으로 선택됩니다.
-
출시 마무리:
- 모든 문제가 해결되고 브랜치가 안정되면 릴리스 브랜치에 의미적 버전(예: v1.2.0) 태그가 지정되어 안정적인 백엔드로의 배포가 시작됩니다.
- 문서화를 위해 릴리스 노트가 생성되어 이해관계자와 공유됩니다.
핫픽스 프로세스
-
핫픽스 분기 생성:
- 긴급 수정이 필요한 경우 최신 프로덕션 태그에서 직접 hotfix/xyz 브랜치를 생성하세요.
- 핫픽스 분기는 릴리스 분기와 동일한 안정화 및 태그 지정 프로세스를 따릅니다.
-
버전 관리:
- 핫픽스는 SemVer(의미 있는 버전 관리) 표준에 따라 패치 버전
(예: v1.2.0에서 v1.2.1로)을 높입니다.
지점 정리
- 혼잡함을 피하기 위해 병합된 분기를 정기적으로 삭제하세요.
- 정리를 유지하려면 사용하지 않는 기능 플래그를 정기적으로 제거하세요.
- GitHub Actions 또는 유사한 도구를 사용하여 병합 후 분기 삭제를 자동화합니다.
대체 QA 및 테스트 전략
쿠키 대신 프로덕션에서 QA 트래픽을 라우팅하기 위한 추가 전략은 다음과 같습니다.
-
헤더 기반 라우팅:
- QA는 요청에 맞춤 헤더(예: X-QA-Test: true)를 추가합니다.
- Nginx는 테스트를 위해 이러한 요청을 새 버전으로 라우팅합니다.
-
IP 기반 라우팅:
- QA의 IP 주소를 기준으로 새 버전으로의 트래픽을 제한합니다.
-
인증 토큰 기반 라우팅:
- QA는 요청이 새 버전으로 라우팅되도록 하는 역할이나 토큰에 연결된 특정 테스트 계정으로 로그인합니다.
결론
이 릴리스 프로세스는 트렁크 기반 개발 및 환경 기반 기능 플래그를 활용하여 확장 가능하고 테스트 가능하며 프로덕션에 안전한 배포 워크플로를 만듭니다. 샌드박스 환경, 트래픽 라우팅 및 전용 테스트 전략을 사용하여 팀은 위험을 최소화하면서 고품질 기능을 제공할 수 있습니다. 이러한 접근 방식을 통해 문제를 조기에 발견하고 효율적으로 해결하여 원활한 기능 출시 및 핫픽스를 위한 기반을 마련할 수 있습니다.
위 내용은 웹 애플리케이션을 위한 간소화된 릴리스 프로세스: 기능 플래그를 사용한 트렁크 기반 개발의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!