"민첩한" 리듬으로 릴리스/브랜치를 유지하고 계십니까?[닫은]

Question

우리는 고객의 요구와 보다 일반적인 로드맵에 맞춰 발전하는 소프트웨어 제품을 보유하고 있습니다.

우리는 SCRUM 프로젝트 환경에 있기 때문에 새로운 기능이 제품에 적용되는 경우가 매우 자주 발생하며 다음 중 하나를 선택해야 합니다.

• 이미 출시된 브랜치에 이 기능을 구현합니다. (그렇다면 실제로 브랜치가 있다는 의미는 아닙니다.)
• 새 브랜치를 만듭니다. 하지만 3주마다 브랜치가 생기고 더 이상 유지 관리할 수 없습니다.

새로운 기능을 출시하지 않는 것은 선택 사항이 아니며 클라이언트는 원하는 기능을 얻기 위한 장기적인 마일스톤 계획을 기다리기를 원하지 않으며 클라이언트 모듈에서 기능을 이동하는 것이 항상 불가능한 것은 아닙니다. 때로는 변경해야 합니다. 제품의 핵심..

그러한 제약 조건이 있는 경우 모범 사례에 대한 피드백이 있는 사람이 있습니까?

Answer 1

현재 환경에서 사용하는 다음을 제안합니다. 계획되지 않은 기능을 보안 수정처럼 취급하십시오.

• 각 계획 릴리스 (예 : 3.0, 3.1)는 자체 버전 번호와 자체 태그를 소스 코드로 가져옵니다. 출시 된 후에는 만지지 않습니다.
• 계획된 릴리스 후 새로운 기능이 다음 계획 릴리스 (예 : 3.2)에 들어갑니다.
• 릴리스 버전의 코드를 수정 해야하는 경우 "계획되지 않은 릴리스"이며 패치 버전 번호 (예 : 3.1.1, 3.1.2)를 얻습니다. 모든 변경 사항 :
  • 해당 릴리스에 대한 최신 패치를 기반으로 새 지점에서 구현되었습니다 (예 : 3.1.1은 3.1.0에서 생성되며 3.1.2는 3.1.1에서 생성됩니다).
  • 즉시 트렁크에 합병되므로 다음 계획 릴리스에도 들어갑니다.
• 계획되지 않은 기능을 구현 한 후에는 분기를 태그로 바꾸고 (일명 더 이상 터치하지 않음) 트렁크에서 작업으로 돌아갑니다.

이런 식으로 계획되지 않은 각 기능은 분기를 얻지 만 새 릴리스를 만들고 트렁크로 합병 할 수있을 정도로 길다. 당신은 거의 모든 일을 한 곳에서 - 트렁크 - 그리고 할 일이 많지 않습니다.

Answer 2

( 'new_feature_branch')와 같은 새로운 지점이 개발 노력 현재 지점과 호환되지 않습니다 ( 'release_branch':)

따라서 현재 릴리스 _branch가 활성화되지 않은 경우 새 기능에 사용할 수 있습니다 (레이블을 정의한 경우. ~ 전에 이 새로운 기능 개발, 해당 프로세스를 취소하고 이전 상태로 돌아 가야하는 경우이 새로운 기능).

새 지점을 만드는 것은 릴리스 지점에서 정기적으로 (3 주마다) 합병 된 후에는 좋은 솔루션이 될 수 있습니다. release_branch (일부 핫 버그 고정)에 활동이있는 경우 특히 권장됩니다. 그런 다음 두 노력을 분리해야합니다.

기본적으로, 그것은 모두 당신에게 내려집니다 워크 플로를 병합하십시오 정의.

내가 당신이 내가 충분히 다루지 않았다고 생각하는 몇 가지 옵션을 자세히 설명하기를 원한다면 의견을 남겨주세요.

Answer 3

내 사무실에서 우리는 일반적으로 특정 시점에서 3 개의 지점에서 일하고 있습니다.

• 릴리스 : 현재 배포 된 코드가 태그 및 저장되는 곳입니다. 중요한 버그 수정을 수행 해야하는 경우 작업이 완료된 곳입니다. 배포되면 일반적으로 태그의 핫픽스 부분을 증가시킵니다 (예 : 1.19.0-> 1.19.1).
• QA : 고객을 위해 준비하는 코드가 태그 및 저장되는 곳입니다. 이 지점은 새로운 작업을 시작할 때 사용되며 다음 배송을 준비하기 위해 현재 QA가 테스트하고있는 코드가 있습니다.
• 메인 : 모든 새로운 작업이 완료된 곳입니다.

드문 경우에는 네 번째 라인에서 개발 해야하는 경우 (매우 긴밀한 릴리스 일정으로 인해) 때때로 샌드 박스 코드 라인을 열 것입니다. 더 일반적으로 우리는 단일 개발자 작업을 분리하여 메인 라인이 지워질 때까지 체크인하지 않을 것입니다.

위의 분기 전략을 통해 우리는 모든 스프린트가 끝날 때 배송으로 주요 기능을 변경할 수있었습니다.

Answer 4

실제로 스크럼 환경에 살고 있는 것 같지 않습니다.스크럼 필요하다 팀은 매 스프린트가 끝날 때마다 완료되어야 하며, 이는 4주 이상 지속되지 않는 것으로 예상됩니다(보통 1~2주).따라서 몇 주에 한 번씩 완전히 테스트되고 실행되며 잠재적으로 배포 가능한 시스템을 갖춰야 합니다.

내가 아는 유일한 방법은 고객과 개발자 테스트 모두에 대해 포괄적이고 완전 자동화된 제품군을 보유하는 것입니다(Extreme 프로그래밍 규정과 같은).

이 경우 왜 브랜치가 필요한지 잘 모르겠지만 왜 유지 관리할 수 없는지 이해하지 못합니다.내 경험에 따르면 지점의 수명이 짧을수록 좋습니다.