개발에 병합 된 기능이 경영진에 의해 연기되면 어떻게됩니까?

53

우리는 최근에 웹앱 (자동 가입) 기능이 시작에 너무 차가워 졌다고 생각했기 때문에 경영진에 의해 연기되는 문제가 있었지만, 우리가 작업했던 다른 모든 기능을 적용하기를 원했습니다.

문제는이 기능이 다음 릴리스에서 라이브로 푸시 할 것으로 예상되는 다른 모든 기능과 함께 개발에 병합되어 일반적으로하는 것처럼 dev-> test-> master를 병합 할 수 없다는 것입니다.

이 문제를 어떻게 피할 수 있었습니까?

project-management git gitflow

— 스티브
소스

해결 방법에 대한 관점에 따라 기술 솔루션을 찾고 있지 않은 경우이 질문이 작업장에 더 적합합니다.

— Malavos

74

한 가지 접근 방식은이를 표시하는 기능입니다. 코드베이스에 살 수 있지만 구성으로 비활성화 할 수 있습니다.

더 이상 개발되지 않도록 기능 병합을 되 돌리는 되돌리기 커밋을 만드는 또 다른 옵션입니다. 되돌리기를 되 돌리는 새로운 브랜치를 만들 수 있으며 나중에 병합하기 위해 남겨 둘 수 있습니다. Github 풀 요청을 사용하는 경우 병합 된 풀 요청의 "병합 되돌리기"버튼을 사용하여이 작업을 쉽게 수행 할 수 있습니다.

— 데니스
소스

9

구성 플래그가 해당 코드에 대한 테스트 노력이 두 배로 증가 함을 의미하지 않습니까? 두 경로를 모두 테스트해야 합니다.

16

이 경우 프로덕션 환경에서 해당 플래그를 설정하지 않으므로 릴리스에 대해 오프 케이스를 테스트 한 다음 즉시 진행할 준비가되면 온 케이스를 테스트 할 수 있습니다. 그것은 되돌리기와 다시 커밋을 테스트하는 것과 거의 같은 작업이어야합니다.

— Alan Shutko

4

일반적인 용어는 기능 토글 입니다. 작은 "기능 진입 점"이 있으면 관리 결정 후에 수행 할 수 있습니다. 그렇지 않은 경우이 방법 및 방법에 문제가 발생합니다.

— Doc Brown

3

Feature TogglingDoc Brown이 말한 것처럼 6 개월 이상 개발 된 기능이 숨겨져 있습니다. 또한 프로덕션 환경이 아닌 환경에서 기능을 테스트 할 수 있습니다. 때로는 이러한 기능이 기존 기능에 추가되므로 이전 기능 세트와 새 기능 세트 모두에 대한 단위 테스트가 필요합니다. 각 단위 테스트는 현재 테스트를 수행하는 데 필요한 모든 플래그를 설정합니다.

— ps2goat

25

이 문제를 어떻게 피할 수 있었습니까?

프로세스 관점에서 다음을 파악하십시오.

이 작업을 시작한 의사 결정자는 누구입니까?
이 기능 출시 결정이 변경된 이유는 무엇입니까?
- 기대를 놓치셨습니까?
- 오해?
- 부적절한 비즈니스 지원?
- 고객 참여가 없습니까?

그 과정에서 의사 소통이 떨어졌을 가능성이 큽니다. 작동하지 않을 때 개발 프로세스가 비즈니스 요구 사항에 대한 허위 및 잘못된 이해에 기초하기 때문에 이것이 중요합니다.

— 엔더 랜드
소스

9

+10. 경영진이 기능의 릴리스를 의심하기 시작하면 기능을 개발에 병합하기로 결정할 때 가능한 제거를 고려할 수 있도록 개발자에게 알려야합니다.

— Bart van Ingen Schenau

14

이것은 매우 건설적인 답변이 아닙니다. 때로는 모든 이유로 모든 측면에서 문제가 발생하기도합니다. 물론, 나중에 합병되지 않아야한다는 사실을 알아내는 것이 중요하지만, 결국에는 마지막 순간에 기능을 끌어낼 수있는 것은 아닙니다. 어쩌면 계약 변경, 고객이 지불하지 않거나 법적 문제가 나타날 수 있습니다. 책임의 손가락을 가리키는 대신 문제를 관리해야합니다

— gbjbaanb

11

귀하의 조직에 결함을 인정하기를 거부 할 정도로 강력하고 결함을 피하지 않으려는 유치한 사람들이 여전히 있다면, 귀하는 자신의 정보에 대해 사후 문제를 여전히 해결해야합니다. 당신은 그들에게 말하고 싶지 않습니다 (또는 너무 명시 적으로 적어 두십시오). 즉, 엔더 랜드는 "비난"이라는 단어를 사용하지 않으며, 조직이이 조언을 "누가 비난 할 것인지를 찾는다"라고 해석하면 조직 자체가 문제가됩니다. 이 모든 것은 "문제가 발생한 이유를 이해하는 것"이며 이는 앞으로 문제를 피하는 데 필수적입니다.

— Steve Jessop

2

전적으로 동의합니다. 이것은 개발자가 아닌 관리 중단입니다.

— durron597

3

@enderland 내 요점은 문제를 피할 수 없으므로 상황을 복구하는 방법을 고려해야한다는 것입니다. 바라건대 당신은 그렇게 자주 얻지 못할 것이지만, 조만간 그렇게 될 것이므로 그에 따라 계획하십시오.

— gbjbaanb

19

관리 문제를 잠시 잊어 버리고 최신 프로덕션 릴리스에 이미 "자동 가입 기능"이 있으며 코드베이스에 깊이 통합되어 있다고 상상해보십시오. 이제 "자동 가입"에 대한 "오프 스위치"를 추가해야하는 새로운 요구 사항이 생겼습니다. Git 워크 플로우에서이 문제를 어떻게 처리 하시겠습니까?

"구성에 의한 자동 가입 비활성화"를 단순히 추가 기능 ( Feature Toggle 의 한 형태)으로 선언하면 워크 플로에 원활하게 통합됩니다. 원하는 경우 기능 분기를 사용할 수 있거나 그러한 문제에 대해 기능 분기를 사용하지 않는 경우 노력을 추정 할 수 있습니다. 그리고 당신은 당신이 묘사 한 usal "merge dev-> test-> master"흐름을 확실히 사용할 수 있습니다.

그리고 이것이 실제로 현재 상황에서이를 처리 할 수있는 방법입니다. git 워크 플로의 관점에서 변경 요청이 릴리스 1.0 관리에서 온 것인지 또는 변경 요청이 릴리스 2.0에 대한 새로운 고객 희망인지는 중요하지 않습니다.

— 닥 브라운
소스

Fowler는 실제로 좋은 출력을 가지고 있지만 기능 소개를 위해이 방법을 지원할 수 없습니다. 이러한 스위치에 대한 조정 된 노력은 불필요한 부담으로 보입니다. 내가 할 수 기능을 추가하는 병합 후 기능을 제거하기 위해 전환하지만, 요구 사항의 일환으로 스위치를 구축하는 것은 나를 불편하게 지원합니다.

— Gusdor

@Gusdor : 내 편집을 참조하십시오.

— Doc Brown

1

이것은 gitflow 및 GitHub 흐름에 대한 정확한 문제이며 웹 응용 프로그램에서는 일반적으로 또는 더 일반적으로 발생하는 것으로 보입니다. 이 문제를 소급하여 (위에서 언급 한) 선제 적으로 (아래 예) 해결하는 것 같습니다.

표준 gitflow 브랜치 외에도 '번들 브랜치'를 만들었습니다. 번들은 uat / qa에 준비된 모든 기능으로 구성됩니다. uat / qa 기능 목록이 작성됩니다. 이들은 임시 번들로 병합되고 해당 번들은 uat / qa에 배포됩니다. 버그 수정은 원래 기능 지점에서 발생하며 번들로 다시 병합되어 배포됩니다. 이를 통해 향후 릴리스를 분리하고 개발 지점으로가는 길을 찾기 전에 해당 기능을 함께 테스트 할 수 있습니다. 승인 된 지점은 gitflow 프로세스에 따라 개발 요청을받습니다. 테스트 준비 기능은 임시 번들 브랜치에 추가하거나 제거하여 재배치 할 수 있습니다.

이를 통해 마스터는 항상 프로덕션 준비 상태를 반영합니다 (훅으로 자동화 가능)
개발은 항상 최신 제공 및 테스트 된 다음 릴리스 후보를 반영합니다.

번들 목록 관리 및 다른 브랜치 유형 추가; 그러나 너무 늦었다 고 생각하는 레트로 픽스 외에도 더 실용적인 해결책 인 것 같습니다.

GUI 애드온을 사용하면 자동화를 염두에두고 번들 배포 당 기능 분기를 선택하는 것이 가장 좋습니다.

— 데이비드 래티
소스