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

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

Linda Hamilton
Linda Hamilton원래의
2024-12-23 21:26:13308검색

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


핵심 원칙

  1. 트렁크 기반 개발:

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

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

Sprint의 JIRA 버전

Streamlined Release Process for a Web Application: Trunk-Based Development with Feature Flags


환경 배포 흐름

  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 />);
     } else {
         render(<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 중국어 웹사이트의 기타 관련 기사를 참조하세요!

성명:
본 글의 내용은 네티즌들의 자발적인 기여로 작성되었으며, 저작권은 원저작자에게 있습니다. 본 사이트는 이에 상응하는 법적 책임을 지지 않습니다. 표절이나 침해가 의심되는 콘텐츠를 발견한 경우 admin@php.cn으로 문의하세요.