답변:
기능 플래그는 장기적인 브랜치 및 제품 개발의 충돌을 피하는 데 사용할 수있는 엔지니어링 장치입니다. 다음은 객체 지향 언어의 컨텍스트를 사용하여 개발자가 특정 제품 기능에 대해 협업하면서 새로운 버전을 처리 할 수 있도록하는 방법입니다. 이 인터페이스는 "인터페이스"라는 개념이 존재하는 경우 객체 지향이 아닌 컨텍스트에서도 사용할 수 있습니다. ( OCaml 모듈 시스템 참조 )
설명을 위해 데이터베이스에 저장된 데이터에 대한 보고서를 제공하는 도구를 가정합니다. 이 코드는 요청을 수행하는 데 사용되는 DatabaseClient 클래스를 구현 합니다. 데이터 세트가 커짐에 따라 일부 대체 데이터 레이아웃이 애플리케이션 성능을 향상시키는 것이 분명해졌습니다. 따라서 Alice 는 향상된 레이아웃으로 구조에서 데이터를 검색 할 수 있는 새로운 버전의 DatabaseClient를 개발하는 한편 Bob 은 기록적인 DatabaseClient를 유지합니다 .
다음 단계를 통해 Alice와 Bob은 단기 브랜치에서 협업하면서 충돌을 최소화 할 수 있습니다.
앨리스 의 이름을 변경 DatabaseClient을 에 DatabaseClient_v1 와라는 대리자 클래스를 만들 DatabaseClient 객체 사용 DatabaseClient_v1 및 구현이라는 인터페이스 DatabaseClientInterface을. 가능한 경우이 DatabaseClientInterface 는 코드 아티팩트 여야하지만 오리 유형 언어는 항상이를 지원하지는 않습니다.
Bob은 Alice가 1에서 변경 한 사항을 검토하고 유지 관리 작업이 DatabaseClient_v1에서 발생해야한다는 것을 알고 있습니다.
Alice는 DatabaseClient 대리자 의 동작을 제어하는 새로운 구성 플래그를 응용 프로그램에 도입하고 DatabaseClient_face 플레이스 홀더를 구현합니다.이 클래스는 모든 메소드가 "구현되지 않음"예외를 발생 시키는 DatabaseClientInterface 를 구현하는 클래스 입니다.
그 후 Alice와 Bob은 각각의 반복으로 작성된 코드가 DatabaseClientInterface의 영향을 받기 때문에 명시적인 동기화없이 협업 할 수 있습니다 . 이는 동시 작업으로 인한 충돌 위험을 최소화합니다.
테스트에서 구현, 메소드 구현 또는 부분적으로 수행하는 것처럼 Alice의 반복 작업은 매우 짧을 수 있습니다. 프로덕션 환경에서는 코드가 사용하도록 선택되지 않았으며 완전히 기능 할 필요가 없기 때문입니다. 자동화있는 TestSuite는 너무 구성해야 DatabaseClientInterface가 항상 사용 DatabaseClient_v1는 앨리스가 쉽게로 전환 할 수 있습니다 동안 DatabaseClient_v2 또는 사용자 정의 CI 설정에서 - 로컬있는 TestSuite를 실행할 때. 모든 것이 준비되면 DatabaseClient 델리게이트를 제어하는 구성 값을 업데이트하여 단일 커밋이 변경을 수행 할 수 있습니다 .
단계는 매우 "쉬운"단계입니다. 기능 플래그 앱으로 이동하려면 기본적으로 두 가지가 필요합니다.
기능 플래그의 기본 기능은 기능을 켜거나 끄는 것입니다. 그러나 신속하게 새로운 기능을 램프 업 방식으로 해제하려고합니다. 예를 들어, 앱을 호스팅하는 5 대의 서버 1 대에 "on"기능이 있습니다. 그런 다음 모든 서버에 "설정"이 될 때까지 다른 서버에서 기능을 켭니다.
즉, 기능이 앱과 호환되지 않도록주의해야합니다 (예 : DB의 추가 열).
프레임 워크는 휠을 재발 명하지 않기 위해 다양한 언어로 존재하며, 현재 유지 관리되지 않은 Etsy의 프레임 워크는 작동 방식을 설명하는 흥미로운 추가 정보 를 제공합니다.
임베디드 소프트웨어 세계는 종종 앱 코드 자체 ( 예 : #define/ #ifdef문) 및 / 또는 빌드 도구 구성 파일 (예 :)에서 빌드 타임 플래그를 사용합니다 makefile.
기능뿐만 아니라 모든 종류의 코드 리팩토링, 마이그레이션, 디버그 지원 등에도 유사한 방식으로 빌드 플래그를 사용할 수 있습니다. 이들은 브랜치에서 이미 작동하는 기능 / 프로젝트에서 빌드를 중단하거나 회귀를 일으키지 않고 통합 브랜치 부분 또는 확인되지 않은 변경 사항을 커밋 할 수 있습니다. 지속적인 통합 방식으로 대규모 / 위험 / 느린 진행 변경 (긴 수명이 필요한 지점)과 함께 포인트 수정을 처리하는 데 탁월합니다.
그러나 이미 존재하는 분기 코드에서 회귀를 검증하는 것 외에도 새 코드의 진행 / 안정성 검증을 수행 할 수도 있습니다. 이를 위해 빌드 타임 플래그를 토글해야합니다.
플래그를 토글하는 한 가지 방법은 동일한 브랜치의 CI 시스템에 대한 별도의 검증 파이프 라인 (이러한 기능을 지원하는 경우)에서 플래그를 토글하는 패치 파일을 사용하여 이전에 별도의 작업 공간에 적용하는 것입니다. 짓다. 이 작업 공간에 다른 아티팩트 세트가 빌드 된 후 확인됩니다.
또는 장기 통합 기능 분기를 기본 통합 분기에서 가져올 수 있지만이 기능 분기의 유일한 변경 사항은 토글 된 플래그입니다. 이 작은 변경으로 인해 기능 분기는 자동으로 매우 빠르게 동기화 될 수 있습니다. 실제로 기본 통합 분기와 매우 밀접하게 섀도 잉됩니다. 이 브랜치에서 별도의 CI 실행에는 더 이상 예비 패치 파일이 필요하지 않습니다. 이러한 기능 분기를 오랜 기간 동안 수행하는 것은 사소한 일입니다.
기본 통합 분기에서 기존 빌드 아티팩트의 복제본이지만 플래그를 토글 한 새 빌드 아티팩트를 작성할 수도 있습니다. 이 방법으로 기본 패치 파일에서 기본 패치 파일이나 기능 분기가 새 코드를 확인하는 데 필요하지 않습니다.