git workflows : 지속적인 배포없이 지형지 물을 통합하고 테스트하는 방법은 무엇입니까?

Question

나는 매우 스콧 차콘에 의해 기술 된 "GitHub의 흐름"워크 플로우를 좋아한다 : GitHub의 빈센트 Driessen (http://nvie.com/posts/a-successful-git-branching-model/)에 의해 기술 된 자식 흐름 워크 플로우를 사용하지 않고, 우리가 그것을 사용하지 않는 이유를 그는 설명 http://scottchacon.com/2011/08/31/github-flow.html

가장 중요한 이유는 끌어 오기 요청과 잘 작동하지 않으며 웹 사이트 개발에 "공식적으로 출시 된 소프트웨어 제품 버전"이 없지만 지속적으로 웹 사이트를 개선하는 것과 같은 이유입니다.

우리는 나쁜 테스트 범위와 함께 오래된 레거시 코드 (일부 코드는 10 년 이상 된)가 많은 소규모 팀으로 대규모 온라인 커뮤니티를 개발하고 있습니다. 우리는 github과 비슷한 워크 플로우를 사용하고 있습니다. 현재는 기능 브랜치를 사용하여 개발하고 풀 요구를 사용하여 마스터 브랜치에 통합하고, 피어 리뷰를하고, 피드백을 요청합니다. 다른 사람이 기능을 완료하고 승인하면, 마스터에 병합되었습니다. 일주일에 몇 번씩 마스터를 테스터 사용자와 베타 사용자가 사용하는 준비 환경으로 밀어냅니다. 우리는 2 주에 한 번 마스터 브랜치를 공개하려고 시도합니다. 따라서 병합 된 모든 기능 브랜치는 충분히 테스트되어야하고, 공개적으로 배포가 완료 될 때까지 "위험한 기능 브랜치"가 병합되지 않습니다.

"위험한 기능"을 마스터에 병합 할 때 다시 마스터가 시작되어 더 이상 공용에 핫픽스를 배포 할 수 없기 때문에 완벽한 워크 플로가 아닙니다.

Github는 배포를 위해 지속적인 배포를 사용합니다. 이는 우리에게 옵션이 아닙니다. 공개하기 전에 기능을 테스트 할 사람이 필요합니다.

끌어 오기 요청은 하나의 분기에만 병합 할 수 있습니다. 따라서 마스터 인 하나의 장기 실행 지점이있는 github에서 직접적인 워크 플로우입니다. 아마도 우리는 2 주에 한번씩 풀어서는 안되지만, 마스터에 병합 될 때 풀 요청을 풀어 주어야할까요? 그러나 테스트하기가 어렵다면 병합되기 전에 지형지 물에 대한 단위 테스트를 실행할 수 있으며 베타 테스터 용 스테이징에 지점을 배치 할 수 있지만 항상 쉽지는 않지만 때로는해야합니다. 수동으로 데이터베이스 변경 (베타 테스터 용 스테이징 서버는 프로덕션 데이터베이스를 사용하기 때문에 자동으로 수행 할 수는 없으므로 위험합니다.) 관리자가 수행 할 때까지 기다려야합니다. 더 큰 문제는 베타 사용자에게 기능 브랜치만을 릴리스하면 통합되지 않고 새로운 기능이 표시되고 하루에 여러 번 제거되는 기능입니다. 통합 테스트를 실행할 수 없거나 기능 분기가 방금 마스터로 병합 될 때 출시 직전에 매우 늦게 실행했다고 가정하지 마십시오.

반면에 다음과 같이 2 개의 장기 실행 분기를 사용하면 개발 및 마스터 git-flow에 설명 된대로, 우리는 핫픽스 문제를 해결할 수 있습니다, 우리는 기능 브랜치를 병합하기 위해 pull-request를 사용할 수 있습니다. 우리는 최근 변경 사항을 마스터에 병합하기위한 릴리스 분기에 대한 pull 요청을 사용할 수 있습니다. 끌어 오기 요청 워크 플로를 사용하여 변경 내용을 병합하여 개발할 수 있습니다.

github 흐름 기사 (검토 후 바로 배포)에서 볼 수 있듯이 github 엔지니어는 프로덕션뿐만 아니라 준비 환경에도 배포 할 수 있습니다. 또한 엔지니어뿐만 아니라 지원 및 설계자에게도 도움이됩니다. 하지만 하나의 통합 지점에서만 어떻게 작동합니까? 마지막 pull 요청이 몇 시간 또는 몇 분 안에 프로덕션으로 진행되는 경우 준비 환경이 필요하지 않습니다. 때로는 기능 브랜치를 스테이징에 배포하는 것으로 보이지만 통합되어 있지 않으므로 위에서 설명한 기능이 배포되기 전에 마스터의 변경 사항을 병합하더라도 스테이징 환경에서오고가는 기능을 볼 수 있습니다. (이것은 좋은 생각이 될 것이라고 생각하십니까?). 또는 모든 기능 지점마다 하나씩 여러 개의 준비 환경을 보유하는 것이 합리적입니까? 그러나 이런 식으로 당신은 지속적인 통합으로 인한 이점을 잃어 버릴 수 있습니다. 그리고 말했듯이, 나는 베타 테스트 환경에서 이것을 할 수 있다고 생각하지 않습니다.

워크 플로, git flow 및 github flow 모두에서 문제가 발생합니다. github flow가 더 좋아 지지만 좋은 테스트 커버리지가없고 사람들이 더 많은 테스트가 필요한 경우 어려워 보입니다.

사람들 (qa 및 베타 테스터)이 더 많은 테스트를해야 할 때 어떻게 지형지 물을 통합하고 테스트 할 수 있습니까?

Answer 1

당신은 하나 개의 공통 통합 분기를 따라 실행 여러 가지 헤드 가질 수 있습니다

----A---B---C---D---E---F---G---H---I 
       \   \   \ 
       goodToGo testing  toBeTested