격주로 프로덕션 릴리스에 즉시 출시 가능한 기능 만 포함시킬 수있는 방법은 무엇입니까?

저는 상당히 큰 민첩한 팀의 소프트웨어 개발자입니다 (8 명의 개발자가 적극적으로 단일 코드 저장소를 변경하고 있음). 2 주마다 새로운 버전의 소프트웨어를 프로덕션 환경으로 푸시합니다. 현재 작업 과정은 다음과 같습니다.

• 새로운 작업을 시작할 때 개발자는 기본 개발 지점에서 "기능 지점"을 만들고 ( git 사용 )이 새로운 지점에서 작업합니다.
• 개발자가 작업 작업을 완료하면 기능 분기를 다시 개발 분기로 병합
• 개발자는 개발 지점을 QA 지점으로 병합합니다.
• QA 브랜치에서 빌드가 트리거됩니다. 이 빌드의 출력은 QA 환경에 배포되어 테스터가 테스트를 시작할 수 있습니다.

테스터가 QA 지점에 통합 된 새로운 기능과 관련된 문제를 찾는 것이 일반적입니다. 즉, QA 환경에는 테스트 및 버그가없고 고장난 몇 가지 새로운 기능이 포함되어있을 수 있습니다. QA 빌드가 프로덕션 준비 상태 인 경우는 드물기 때문에 릴리스하기가 어렵습니다.

이를 완화하기 위해 개발자는 출시 2 일 전에 개발자가 개발 지점을 QA 지점으로 병합하지 않는 "QA 동결"을 시작하려고했습니다. QA 환경에 대한 버그 수정은 QA 브랜치에서 직접 이루어지며 개발 브랜치로 병합됩니다. 이론적으로 이것은 QA에서 새로운 깨진 기능을 유지하면서 QA에서 이미 문제를 해결할 수 있습니다.

이 "QA 동결"개념이 부분적으로 성공했지만 조정하기가 어렵고 사람들이 QA에 병합 할 수 있는지에 대해 종종 혼란스러워합니다. "QA 동결"마감일을 정하기도 어려웠습니다. 모두가 동결과 릴리스 사이에 숨을 쉬는 방에 대한 아이디어를 좋아하지만 실제로는 다음 릴리스에서 마감일을 지키는 것보다 기능이 더 좋습니다.

격주로 릴리스를 깔끔하게 빌드 할 수있는 더 좋은 방법이 있습니까?

이 문제 주위에 떠 다니는 몇 가지 문제가 있습니다.

첫 번째는 장기 실행 QA 지점입니다. QA 지점과 메인 라인 모두에서 복제해야하는 다른 노력이 있기 때문에 개발 메인 라인과 평행 한 장기 실행 브랜치를 갖는 것은 혼란의 원인이 될 수 있습니다. 즉, 메인 라인에 병합해야하는 QA 브랜치 (잘못된 것은 아님)에 대한 수정 사항을 체크인 중이거나 QA 브랜치에 병합 된 메인 라인에 체크인 중입니다 (버그의 원인) .

장기간 실행되는 병렬 분기의 다른 문제는 파일이 영구적으로 동기화되지 않을 수 있다는 것입니다. 다시 병합되지 않는 코드 수정 또는 테스트되지 않고 개발 메인 라인의 일부인 프로덕션 빌드에 필요한 구성.

다음으로 영향을받는 역할이 있습니다. 이는 패키징 역할 (나중에 자세히 설명)이 충분히 격리되지 않음을 의미합니다.

에서 자식 흐름 모델, 박리 브랜치 (현상으로부터 분기되어 있지 QA 병합 개발) 및 모든 수정은 방출 지점에 체크 한 후 다시 현상 분기 합병.

브랜칭 철학 중 일부는 Advanced SCM Branching Strategies 에서 볼 수 있습니다 . 이는 각 지점이 수행 할 수있는 역할에 중점을 둡니다. 릴리스 지점은 포장 역할을 담당합니다.

패키징 역할은 종종 누적 또는보다 일반적으로 주요 역할과 혼동됩니다. 의도 된 개발 및 유지 보수가 수행되고 누적이 완료되면 코드 릴리스를 준비해야합니다. 이러한 노력은 사소하지 않을 수 있으므로 릴리스 엔지니어 팀과 이미 수행 한 것 이상의 추가 수정이 필요합니다. 패키징 지점의 정책은 유지 보수 지점의 정책과 크게 다르며, 패키징 역할에서 알 수 있듯이 제품을 출시하기 위해 필요한 변경 사항 만 해결해야합니다.

• 개발 지점에서 릴리스 지점으로 분기합니다. QA가 빌드하는 릴리스 브랜치는 하나의 브랜치를 가져오고 개발에서 병합하지 않습니다.
  • 일관된 이름 지정 및 후크를 사용하여 해당 도로를 내려 가려면 릴리스 분기로 병합이 수행되는 것을 방지 할 수 있습니다.
• 릴리스 브랜치에서 수정해야하는 모든 것을 수정하고 해당 변경 사항을 다시 메인 라인에 병합하십시오.
• 릴리스 노력이 끝나면 릴리스 분기를 "releases go here"분기로 병합하고 태그를 지정하십시오.
  • 일부 사이트에는 "releases go here"분기가없고 릴리스 분기의 끝 부분에 태그가 붙어 있습니다.

전체 git-flow 전체를 적용하는 것을 진지하게 고려해야합니다. 이것은 현재 행해지고있는 것과 크게 다르지 않으며 각 지사가 의미하는 것과 각 지사가 다른 사람과 어떻게 상호 작용하는지에 대한 훈련과 일관성을 제공합니다.

문제는 단일 QA 지점이 있다는 것입니다.

각 릴리스마다 기본 개발 트렁크 / 마스터 와 별도의 QA 지점을 만듭니다 . 그런 다음 해당 지점의 기능 버그에 대한 수정 사항 만 병합하십시오 . 새로운 기능은 없습니다. 품질 관리팀에서 해당 지점을 테스트하도록합니다.

이런 식으로 "동결"은 아주 분명합니다. 그것은 지사 이름에 있습니다. 당신은 같은 것을 사용할 수 있습니다 release/26/10/2015. 그런 다음 아무도 새로운 기능에 합류해서는 안됩니다.

동결 될 때까지 분기를 포크하지 않더라도 특히 유용합니다. 사람들은 언제든지 마스터에 합류 할 수 있습니다. 테스트를 위해 제 시간에 완료되지 않은 경우에는이 릴리즈에 포함되지 않습니다.

오래 실행되는 QA 지점이 하나도 없어 문제가 될 수 있습니다. 각 릴리스의 주요 개발 지점에서 포크하고 해당 지점에서 QA합니다.

아래 보이는 Development-MAIN-Production 분기 모델에 다소 매핑되어 있습니다. MAIN 위의 영역은 개발 영역이라고합니다. MAIN 아래 영역은 생산 영역입니다.

이 모델의 주요 특징은 다음과 같습니다.

• 개발자는 최신 변경 사항이 항상 최신 전체 개발을 고려할 수 있도록 FI (Forward Integrate) (FI = MAIN에서 주 단위로 병합)를 DEV 분기로 자주 전달해야합니다.
• 개발자는 QA에 노출하려는 기능 완료 이정표에 도달하고 신속한 수정을 제공 할 준비가 된 경우 에만 테스트 지점에서 리버스 통합 (RI) (RI = MAIN으로 병합) 해야합니다. 품질 관리 피드백에 대한 답변. 수정은 테스트 분기에서 수행되고 DEV 분기에서 즉시 FI가 수행됩니다.
• 결코 홈페이지에 어떤 DEV 지점에서 RI
• QA가 TEST 품질이 양호하다고 간주 할 때만 TEST 지점에서 MAIN으로 항상 RI를 이동하십시오. MAIN에 병합하기 위해 고품질 임계 값을 유지하십시오. 최소한 제품 관리자는 MAIN의 최신 커밋에서 항상 제품의 실제 버전을 시연 할 수 있어야합니다.
• 필요한 경우에만 생산 영역에 분기를 작성하십시오. 빌드 서버는 항상 개발 영역의 분기를 포함하여 모든 분기에 태그를 지정해야하며 빌드 / 릴리스의 소스는 원래 분기에 관계없이 항상 식별 가능해야합니다.
• MAIN 또는 프로덕션 영역에서만 프로덕션 용 릴리스를 수행하십시오. 나중에 정확히 출시 된 버전에 대한 수정 사항을 제공해야하는 경우 (즉, MAIN에서 최신 버전을 제공 할 수 없음) 수정 사항이 필요한 경우 결함이있는 릴리스의 MAIN 태그에서 프로덕션 영역에 브랜치를 작성하십시오. 항상 HotFix 브랜치에서 문제를 해결 한 다음 즉시 RI를 MAIN으로, FI를 TEST로

다음과 같은 이유로 문제가 있다고 생각합니다.

• 기능 이정표가 아닌 테스트 코드에 대한 개발자 RI
• QA에서 초록불을받지 않고 개발자 RI를 TEST로 (예 : QA가 TEST에 주입되는 것을 제어하지 않음)
• QA가 TEST에서 버그를보고하면 개발자는 DEV 분기에서 버그를 수정 한 다음 RI를 TEST로 수정합니다. 병합이 항상 다른 불완전한 개발 쓰레기를 가져올 것이기 때문에 이것은 나쁜 나쁜 습관 입니다. 항상 TEST에 고정한 다음 FI를 DEV 브랜치에 고정해야합니다. 테스트에서 수정할 수 없으면 처음부터 전체 쓰레기를 전달했으며 더 큰 문제가 있습니다.
• 귀하의 개발자는 TEST에서 충분히 FI를 얻지 못하므로 TEST를 전달할 때마다 TEST를 불안정하게 만듭니다. DEV에 FI하는 빈도를 균형있게 유지하는 훌륭한 예술입니다. 너무 많이 연기하면 납품 직전에 비용이 많이 들고 위험 할 수 있습니다. 너무 자주하고 TEST에있는 다른 사람들이 제공 한 작업과 너무 많이 겹치는 경우 실제 개발 작업을 수행하지 않습니다.

질문을 이해하면 두 가지 문제가 있습니다. (a) 깨진 기능이 해제하려는 좋은 기능과 병합되고 있습니다. (b) 깨진 기능을 유지하면서 좋은 기능을 해제 할 수 있기를 원합니다. 가능한 솔루션에 대한 제약으로 최종 릴리스 / 공식 QA 테스트가 다음 릴리스에 예정된 모든 기능이 포함 된 통합 브랜치에서 수행되기를 원한다고 가정합니다.

SCM 분기 모델에 관계없이 다음 중 하나 또는 둘 모두를 시도하는 것이 좋습니다.

1. 각 기능 팀에 QA 리소스를 할당하십시오. 기능 분기에서 빌드시 기능 테스트를 수행하고 기능을 병합하기에 충분한시기를 결정할 권한을 부여하십시오. 이상적으로는 (기능 팀과) 나머지 팀과 공동으로 작업하게하므로 작성 후 바로 테스트합니다. (그렇다고해서 모든 테스트 자체를 수행해야하는 것은 아닙니다.)
2. 기능 분기 대신 또는 추가로 기능 전환을 사용하십시오. 기능 전환을 사용하면 코드에서 병합을 해제하지 않고도 손상된 기능을 끌 수 있으므로 다른 기능을 테스트하고 릴리스 할 수 있습니다. 내가 말하는 토글은 고객이 접근 할 수 없습니다. 테스트를 위해 기하 급수적으로 증가하는 조합을 원하지 않습니다. QA 브랜치에서 해제하려는 기능과 일치하도록 토글을 설정하고, 기능이 준비되지 않아 계획이 변경되면 해당 토글을 변경합니다.

내가 당신보다 약간 큰 팀에서 일하는 것을 본 매우 간단한 해결책은 모든 사람이 단일 지점에서 일하고 배포하도록하는 것입니다.

팀이 민첩하다고 말하지만 스프린트 (예 : 스크럼) 또는보다 지속적인 흐름 (예 : 칸반) 방식으로 작업하고 있는지는 확실하지 않습니다. 스프린트를 수행한다고 가정하면 팀의 목표는 각 스프린트가 끝날 때마다 코드를 릴리스 할 수 있도록하는 것입니다. 한 기능이 모두 함께 개발 되었기 때문에 한 기능이 다른 기능을 중단할지 여부에 대해서는 혼동되지 않습니다. 테스터는 개발자가 제공하는 오버 헤드가 적으므로 더 작은 기능으로 기능에 액세스 할 수 있습니다. 또한 QA 동결이 실제로 필요하지는 않습니다. 대신 스프린트의 끝이 언제인지를 알고 있으며 완료 할 수 없거나 배치 할 수없는 (즉, 비활성화 된) 상태로 남겨 둘 수없는 작업을 수행해서는 안됩니다.

분명히 어떤 접근법에도 장단점이 있습니다. 필자는 이것이 반드시 '최상의 방법'이 아닌 옵션으로 제시합니다.

이러한 문제가 발생하는 이유는 품질 보증으로 출시 된 코드의 품질이 충분하지 않기 때문에 (그리고 누구입니까?!) QA에 더 나은 릴리스를 시작해야 큰 수정을 자주받을 필요가 없기 때문입니다. 이 작업을 수행하는 가장 간단한 방법은 릴리스 한 중간 브랜치를 도입하는 것입니다 (테스트라고 함). 아직 개발이 진행 중이지만 개발자는 계속해서 작업을 진행할 수있을뿐만 아니라 QA로 전송하기에 충분한 품질의 통합 브랜치를 보유하고 있습니다.

QA에서 현재 발견하고있는 버그를 찾기 위해이 분기에서 통합 테스트를 수행 할 수 있으며, 원래 분기에서 버그를 수정 한 다음 다시 병합 할 수 있으며,이 분기에서 오른쪽 또는 버그를 직접 수정할 수있을 때까지 다시 병합 할 수 있습니다. 전자). 일단 기본적인 테스트를 통과하면 '사용자의 끈적 끈적한 손가락과 그게 뭐야?'를 위해 QA로 보낼 수 있습니다. 테스트.

따라서이 접근 방식은 기능이 제대로 코딩되지 않았거나 예기치 않은 통합 문제가 중요하지 않은지 여부에 관계없이 QA 브랜치가 손상된 개발 기능으로부터 보호하도록 설계되었습니다. 통합 테스트를 통과 한 개발 지점 만 QA로 승격됩니다.