웹 애플리케이션을 위한 간소화된 릴리스 프로세스: 기능 플래그를 사용한 트렁크 기반 개발

이 기사에서는 트렁크 기반 개발 및 환경 기반 기능 플래그를 중심으로 구축된 웹 애플리케이션을 위한 강력하고 효율적인 릴리스 프로세스를 간략하게 설명합니다. 이 방법론은 고품질 표준을 유지하면서 지속적인 통합, 손쉬운 프로덕션 테스트, 개발에서 릴리스까지의 원활한 경로를 보장합니다.

---

핵심 원칙

1. 트렁크 기반 개발:

   • 트렁크 브랜치는 모든 개발 작업에 대한 단일 정보 소스 역할을 합니다.
   • 개발자는 새로운 기능이나 Jira 티켓을 위해 트렁크에서 기능 브랜치(예: feature/xyz)를 생성합니다.
   • 풀 요청(PR)은 성공적인 테스트 후 검토 및 병합을 위해 이러한 기능 브랜치에서 트렁크로 제출됩니다.

2. 환경 기반 기능 플래그:

   • 기능 플래그는 환경 전반에 걸쳐 기능 활성화를 제어하는 ​​데 사용됩니다.
   • 플래그는 환경별 구성 파일에 저장되거나 CI/CD 파이프라인 구성의 일부로 저장됩니다.
   • Trunk 브랜치에서는 기본적으로 모든 기능 플래그가 OFF로 설정되어 있습니다.
   • 필요에 따라 특정 환경(예: 샌드박스, 스테이징 또는 프로덕션)에서 플래그를 ON 토글할 수 있습니다.

---

Sprint의 JIRA 버전

---

환경 배포 흐름

1. 샌드박스 또는 스테이징 환경:

   • QA 및 통합 테스트를 위해 팀은 트렁크에서 sandbox/(예: sandbox/xyz) 접두사가 붙은 분기를 생성할 수 있습니다.
   • 이 브랜치는 CI/CD 파이프라인을 사용하여 전용 샌드박스 또는 스테이징 환경에 배포됩니다.
   • QA 팀은 새로운 기능을 검증할 수 있으며 통합 테스트는 호환성을 보장할 수 있습니다.
   • 이 환경에서는 특정 기능을 테스트하기 위해 기능 플래그가 켜짐 전환됩니다.

2. 제품 출시 준비:

   • 릴리스를 준비하려면 트렁크에서 release/xyz 브랜치를 생성하세요.
   • release/xyz 분기는 릴리스 후보 역할을 하며 처음에는 베타 테스트를 위해 프로덕션 트래픽의 5%에 배포됩니다.
   • 새로운 기능에 대한 기능 플래그는 프로덕션 환경에서 테스트할 수 있도록 이 분기에서 ON으로 전환됩니다.
   • Nginx 또는 유사한 로드 밸런서는 이러한 트래픽 분할을 처리하여 일부 사용자에게만 변경 사항이 표시되도록 할 수 있습니다.

---

기능 플래그: 예 및 사용법

1. 플래그 구조:

   • 구성 파일(예: config/feature-flags.json)에 기능 플래그를 저장합니다.

    {
      "feature_xyz": false,
      "feature_abc": true
    }
   

• 환경 변수를 사용하여 런타임 중에 플래그를 제어합니다.
  

   FEATURE_XYZ=true FEATURE_ABC=false npm start
  

1. 백엔드 예:

   • 코드에서 플래그를 전환합니다.

    const featureFlags = require('./config/feature-flags');
   
    if (featureFlags.feature_xyz) {
        console.log('Feature XYZ is enabled!');
    } else {
        console.log('Feature XYZ is disabled.');
    }
   

2. 프런트엔드 예:

   • 플래그를 사용하여 UI 구성요소를 조건부로 렌더링합니다.

    if (process.env.REACT_APP_FEATURE_XYZ === 'true') {
        render(<newfeaturecomponent></newfeaturecomponent>);
    } else {
        render(<oldfeaturecomponent></oldfeaturecomponent>);
    }
   

3. 테스트 중 플래그 전환:

   • 테스트용 플래그를 전환하려면 구성 또는 환경 변수를 업데이트하고 관련 서비스(프런트엔드 또는 백엔드)를 다시 시작하세요.

    FEATURE_XYZ=true npm start
   

• CI/CD 파이프라인의 경우 배포 중에 적절한 플래그 값이 환경에 삽입되었는지 확인하세요.

---

프로덕션 테스트

1. 베타 테스트를 위한 트래픽 라우팅:

   • 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%를 새 버전을 실행하는 서버로 라우팅합니다.

1. 프로덕션 전용 QA 테스트:
   • QA 팀은 요청에 맞춤 쿠키(예: qa-test=true)를 첨부할 수 있습니다.
   • Nginx는 이 쿠키를 확인하고 이러한 요청을 100% 새 버전으로 라우팅하여 프로덕션에서 타겟 테스트를 보장합니다.

---

출시 안정화

1. 문제 해결:

   • 개발자는 트렁크 브랜치에 PR을 열어 베타 테스트 중에 확인된 문제를 해결합니다.
   • 병합된 후에는 이러한 수정 사항이 release/xyz 브랜치에 선별적으로 선택됩니다.

2. 출시 마무리:

   • 모든 문제가 해결되고 브랜치가 안정되면 릴리스 브랜치에 의미적 버전(예: v1.2.0) 태그가 지정되어 안정적인 백엔드로의 배포가 시작됩니다.
   • 문서화를 위해 릴리스 노트가 생성되어 이해관계자와 공유됩니다.

---

핫픽스 프로세스

1. 핫픽스 분기 생성:

   • 긴급 수정이 필요한 경우 최신 프로덕션 태그에서 직접 hotfix/xyz 브랜치를 생성하세요.
   • 핫픽스 분기는 릴리스 분기와 동일한 안정화 및 태그 지정 프로세스를 따릅니다.

2. 버전 관리:

   • 핫픽스는 SemVer(의미 있는 버전 관리) 표준에 따라 패치 버전
   (예: v1.2.0에서 v1.2.1로)을 높입니다.

---

지점 정리

• 혼잡함을 피하기 위해 병합된 분기를 정기적으로 삭제하세요.
• 정리를 유지하려면 사용하지 않는 기능 플래그를 정기적으로 제거하세요.
• GitHub Actions 또는 유사한 도구를 사용하여 병합 후 분기 삭제를 자동화합니다.

---

대체 QA 및 테스트 전략

쿠키 대신 프로덕션에서 QA 트래픽을 라우팅하기 위한 추가 전략은 다음과 같습니다.

1. 헤더 기반 라우팅:

   • QA는 요청에 맞춤 헤더(예: X-QA-Test: true)를 추가합니다.
   • Nginx는 테스트를 위해 이러한 요청을 새 버전으로 라우팅합니다.

2. IP 기반 라우팅:

   • QA의 IP 주소를 기준으로 새 버전으로의 트래픽을 제한합니다.

3. 인증 토큰 기반 라우팅:

   • QA는 요청이 새 버전으로 라우팅되도록 하는 역할이나 토큰에 연결된 특정 테스트 계정으로 로그인합니다.

---

결론

이 릴리스 프로세스는 트렁크 기반 개발 및 환경 기반 기능 플래그를 활용하여 확장 가능하고 테스트 가능하며 프로덕션에 안전한 배포 워크플로를 만듭니다. 샌드박스 환경, 트래픽 라우팅 및 전용 테스트 전략을 사용하여 팀은 위험을 최소화하면서 고품질 기능을 제공할 수 있습니다. 이러한 접근 방식을 통해 문제를 조기에 발견하고 효율적으로 해결하여 원활한 기능 출시 및 핫픽스를 위한 기반을 마련할 수 있습니다.

위 내용은 웹 애플리케이션을 위한 간소화된 릴리스 프로세스: 기능 플래그를 사용한 트렁크 기반 개발의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!