기능 플래그 토글을 사용하도록 개발자를 설득하는 방법?

기능 플래그 토글이 좋은 아이디어라고 가정하고 개발자가 작성하는 코드로 구현해야합니다. 예를 들어 Etsy 는 그들의 문화 의 주요 부분으로 그들에 의해 맹세합니다 .

기능 플래그 토글을 사용하도록 개발자를 설득하고 강제하는 좋은 방법은 무엇입니까?

기능 플래그 토글에 대한 자세한 내용은 Q : 기능 플래그 토글 사용 방법 , Q : 기능 플래그 토글이란 무엇이며 Martin Fowler의 블로그 주제에 대한 Pete Hodgson의 기사 에서 매우 광범위하게 설명됩니다 .

피처 토글은 릴리즈와 개발을 분리 하기 때문에 고속 개발에서 일반적 입니다. 개발자 팀은 비활성화 된 상태에서 프로덕션에 새로운 기능을 "소프트 릴리스"할 수 있습니다. 이를 통해 언제든지 기능을 해제 할 수 있습니다. 이 기능이 다른 작업이나 준비에 의존하는 경우 주요 릴리스가 프로덕션으로 이동하기를 기다릴 필요가 없습니다.

개발자가 "설득력있게"사용하는 한, 그것이 제공하는 자유를위한 사례를 만드는 연습입니다. 내 경험은 개발자에게 힘든 판매가 아니라는 것입니다. 새로운 일을 시도하는 것을 꺼리는 경향이있는 관리입니다. 이 시도:

• 기능 토글 프레임 워크를 찾으십시오. 관리 / 비즈니스는 공통 시스템이 지원하는 것을 시도하기가 더 쉬울 수 있습니다
• 작게 시작하십시오. 유틸리티를 시연 할 기능에 대해 시험 방식으로 토글 시스템을 도입하십시오.
• 토글의 A / B 테스트 기능을 보여줍니다. 웹 팜의 하위 집합에 대해 토글을 활성화 한 다음 동작에 대한 메트릭을 수집하십시오. 페이지 레이아웃의 작은 차이는 소매 애플리케이션 (예 : Ebay, Amazon)의 매출에 큰 영향을 미치는 것으로 입증되었습니다.

이상적인 세상에서 나는 당신이 새로운 빌드와 놀라움을 내놓았다 고 생각합니다! 아무것도 바뀌지 않았습니다. 모든 새로운 기능이 스위치를 끄면 꺼지는 스위치 뒤에 있기 때문입니다.

배포 후 롤아웃 된 서비스가 여전히 작동하는지 확인하고 전화가 더 이상 울리지 않는지 확인합니다 (벨 울림 전화가 목적이 아닌 경우 등). 알려진 안정적인 작업으로 돌아 오면 활성화 및 확인을 시작합니다. 새로 배포 된 기능

답을 찾으십시오. 전화를 거는 것이 실질적으로 어려운 팀에서 어떻게 일하고 싶습니까? 사이트와 서비스가 안정적으로 안정적이기 때문에 사용자가 우리를 사랑합니까?

그것이 제가 작업하고 싶은 팀입니다.

원한다면 여기서 읽기를 중단 할 수 있습니다.

기능 스위치 뒤에 모든 것을 넣으면 어디에서나 스파게티 코드로 이어질 수 있습니다. IoC를 사용하고 vNow / vNext / vPrevious 중에서 선택할 수있는 경우 구성을 유지 관리해야합니다. 더 많은 체크인, 예 더 많은 클래스 (componentV1, componentV2, componentV3 등)가 있지만 실제로보다 안정적인 시스템이 있습니까? 방법? vNext는 엉뚱합니까? 컨트롤 타워를 사용하여 vNow로 다시 전환하십시오. 일주일 동안 vNow에 미묘한 버그가 있습니까? 같은 것-쉽게 vPrevious로 돌아갑니다.

번거 로움, 걱정, 수면 손실, 스트레스 없음.

이것은 파이프 꿈이 아닙니다. 나는 거기서 일했었다. 이 팀을 현재 팀에 판매 할 수 있기를 바랍니다.

성공적인 고속 개발 환경은 일반적으로 회귀를 유발하는 잘못된 변경을 감지 및 거부하는 품질 검증을 포함하는 매우 엄격한 자동화 시스템에 의존합니다.

기능 토글은 통합 브랜치에서 회귀를 유발하는 것을 거부하지 않고 진행중인 테스트되지 않은 변경 사항을 커밋 할 수있는 기능을 제공합니다. 기능을 소개 하는 데 매우 좋은 인센티브 를 구성하는 요소는 기능 수명 초기에 전환됩니다.

진정한 CI에서 벗어나 기능 지점에서 기능 개발을 이동하는 단점 중 하나는 그러한 인센티브가 없다는 것입니다. 기능 분기를 통합 분기에 병합 할 때 나중에 기능 토글을 추가하는 것은 늦은 통합과 같이 일반적으로 더 어렵습니다.

개발자 (및 일반적으로 개발 관리자)는 일반적으로 프레임 워크와 관련된 두 가지 결과, 관리 용이성 및 배포 속도를 찾습니다. 코드를 더 빠르고 쉽게 배송하려고합니다.

접근 방식이 효과적이라는 증거를 제공하십시오. 기능 플래그와 기존 방식을 사용하여 작은 POC를 작성하십시오. 사례 연구는 전략적 사람들 (중간 관리 \ 제품 디자이너)보다 전술적 사람들 (개발자 / 엔지니어)에게 덜 중요합니다.

기능 토글을 갖는 이론적 근거는 개발자가 결정할 것이 아닙니다. 이것은 제품 소유자가 관리해야 할 내용입니다. 개발자는 이러한 변화를 가장 지속 가능하고 안전하게 수행 할 수 있습니다. 나는이 질문에 비판한다.