테스트/QA 프로세스와 통합된 Git 분기 전략

테스트/QA 프로세스와 통합된 Git 분기 전략

우리 개발 팀은 GitFlow 분기 전략을 사용해 왔고 그것은 훌륭했습니다!

최근에 소프트웨어 품질을 개선하기 위해 몇 명의 테스터를 모집했습니다.이 아이디어는 모든 기능을 테스터가 테스트/QA해야 한다는 것입니다.

한 후 피쳐 로 병합합니다.develop가지를 치다개발자는 그것에 대해 그의 작업을 직접 테스트할 것입니다.feature분점. 과 함께 이 질문을 하겠습니다.

테스터가 새로운 기능을 테스트해야 하는 분기는 무엇입니까?

분명히 두 가지 옵션이 있습니다.

• 개별 기능 분기에
• 에서.develop

개발 분기에서 테스트 중

처음에는 다음과 같은 이유로 이 방법이 확실하다고 생각했습니다.

• 에 병합된 됩니다.develop그것은 개발이 시작되었기 때문에 지점.
• 충돌이 발생하기 전에 탐지될 수 있습니다.
• 테스터의 일을 쉽게 해준다, 그는 단지 하나의 지점을 다루고 있을 뿐이다)develop 항상. 는 관련롭게 관리하는 브랜치)을가 없습니다.

이와 관련된 가장 큰 문제는 다음과 같습니다.

• 그develop나뭇가지가 벌레로 오염되었습니다.

  테스터가 버그나 충돌을 발견하면 개발자에게 다시 보고합니다. 개발자는 개발자가 문제를 해결합니다(기능 분기는 병합된 후에 포기됨). 이후에 더 많은 수정이 필요할 수 있습니다.의 후속 또는 가 off로 )developbugs)는을 그버에수위롤분기다니서합백능에서 .develop가능하면 분기가 매우 어렵습니다.에 병합 및 수정되는 여러 기능이 있습니다.develop분기가 다릅니다.따라서 일부 기능만 포함된 릴리스를 생성하려는 경우 큰 문제가 발생합니다.develop 분점

기능 분기에 대한 테스트

그래서 우리는 다시 생각해보고 기능 분기에서 기능을 테스트해야 한다고 결정했습니다.테스트하기 전에 변경 사항을 통합합니다.develop로 분기(Catch feature branch( 분기를 캐치업))develop지점) 이것은 좋습니다.

• 메인스트림의 다른 기능을 사용하여 기능을 여전히 테스트합니다.
• 추가 개발(예: 버그 수정, 충돌 해결)은 오염되지 않습니다.develop 지점; 지점;
• 기능이 완전히 테스트되고 승인될 때까지 기능을 릴리스하지 않을 것인지 쉽게 결정할 수 있습니다.

하지만 몇 가지 단점이 있습니다.

• 테스터는 코드 병합을 수행해야 하며, 충돌(가능성이 매우 높음)이 있을 경우 개발자에게 도움을 요청해야 합니다.우리의 시험관들은 시험을 전문으로 하고 코딩을 할 수 없습니다.
• 에 두 못합니다 예를 들어, 기능 A와 B는 동시에 테스트 중입니다. 두 기능이 모두 통합되지 않았기 때문에 두 기능은 서로를 알지 못합니다.develop분점.이것은 당신이 그것에 대해 테스트해야 한다는 것을 의미합니다.develop두 기능이 모두 개발 분기에 병합될 때 다시 분기합니다.그리고 여러분은 미래에 이것을 테스트하는 것을 기억해야 합니다.
• 기능 A와 B가 모두 테스트 및 승인되었지만 병합된 경우 충돌이 확인되면 두 기능의 개발자 모두 해당 기능의 분기가 테스트를 통과했기 때문에 자신의 오류/작업이 아니라고 생각합니다.의사소통에는 여분의 간접비가 있으며, 때때로 갈등을 해결하는 사람이 누구든 좌절합니다.

---

위는 우리의 이야기입니다.제한된 리소스로 모든 곳에서 테스트하는 것을 피하고 싶습니다.우리는 여전히 이것에 대처할 더 나은 방법을 찾고 있습니다.저는 다른 팀들이 이런 상황에 어떻게 대처하는지 듣고 싶습니다.

이를 수행하는 방법은 다음과 같습니다.

기능 분기에 대한 최신 개발 분기 코드를 병합한 후 기능 분기에서 테스트합니다.주요 이유는 기능이 승인되기 전에 개발 분기 코드를 "오염"하지 않기 때문입니다.테스트 후 기능이 승인되지 않지만 개발 시 이미 병합된 다른 기능을 릴리스하고 싶은 경우 지옥이 될 수 있습니다.개발은 릴리스가 생성되는 분기이므로 릴리스 가능한 상태에 있어야 합니다.긴 버전은 여러 단계로 테스트하는 것입니다.보다 분석적으로:

1. 개발자는 모든 새 피쳐에 대해 피쳐 분기를 작성합니다.
2. 기능 분기는 개발자가 테스트할 때마다 TEST 환경에 자동으로 배포됩니다.
3. 개발자가 배포를 완료하고 기능을 테스트할 준비가 되면 기능 분기의 develop 분기를 병합하고 TEST에 대한 모든 최신 개발 변경 사항이 포함된 기능 분기를 배포합니다.
4. 테스터는 TEST에서 테스트를 합니다.작업이 완료되면 그는 스토리를 "수용"하고 개발 단계에서 피쳐 분기를 병합합니다.개발자가 이전에 기능에 대한 개발 지점을 병합했기 때문에 일반적으로 너무 많은 충돌을 예상하지 않습니다.하지만 그런 경우라면 개발자가 도울 수 있습니다.이것은 까다로운 단계입니다. 이를 방지하는 가장 좋은 방법은 기능을 가능한 한 작게/구체적으로 유지하는 것입니다.서로 다른 기능은 결국 어떤 방식으로든 병합되어야 합니다.물론 팀의 규모는 이 단계의 복잡성에 영향을 미칩니다.
5. develop 브랜치도 TEST에 자동으로 배포됩니다.우리는 기능 브랜치 빌드가 실패할 수 있지만 개발 브랜치는 실패하지 않아야 한다는 정책을 가지고 있습니다.
6. 기능 동결에 도달하면 개발에서 릴리스를 만듭니다.이는 스테이징에 자동으로 배포됩니다. 프로덕션 배포 전에 광범위한 엔드 투 엔드 테스트가 수행됩니다.(좋아요, 제가 조금 과장할 수도 있지만 그들은 매우 광범위하지는 않지만 그렇게 해야 한다고 생각합니다.)베타 테스터/동료, 즉 실제 사용자가 그곳에서 테스트하는 것이 이상적입니다.

이 접근법에 대해 어떻게 생각하십니까?

테스트하기 전에 개발 분기에서 피쳐 분기로 변경 사항을 병합합니다.

아니요. 특히 '우리'가 QA 테스터인 경우에는 하지 마십시오.병합은 잠재적 충돌을 해결하는 것을 포함하며, 이는 QA 테스터(가능한 한 빨리 테스트를 진행해야 함)가 아닌 개발자(코드를 알고 있음)가 가장 잘 수행합니다.

개발자가 위에서 자신의 분기를 리베이스하도록 하고 해당 분기를 푸시합니다(개발자가 가장 최근에 컴파일하고 작업한 것으로 검증됨).devel분기 상태).
다음과 같은 이점이 있습니다.

• 기능 분기에 대한 매우 간단한 통합(고속-포워드 병합 포함).
• 또는 아래의 의견에서 Asasia가 추천한 대로 풀 요청(GitHub) 또는 병합 요청(GitLab): 유지 관리자는 기능 PR/MR 분기와develop그러나 GitHub/GitLab에서 충돌이 감지되지 않는 경우에만 가능합니다.

검사자는 버그를 발견할 때마다 개발자에게 보고하고 현재 기능 분기를 삭제합니다.
개발자는 다음을 수행할 수 있습니다.

• 병을 고치다
• 최근에 가져온 develop 브랜치 위에 rebase(다시 말하지만, 해당 코드가 다른 검증된 기능과 통합되어 작동하는지 확인)
• 밀다, 밀다, 밀다, 밀다, 밀다feature분점.

일반적인 아이디어: 개발자가 병합/통합 부분을 수행하는지 확인하고 테스트는 QA에 맡깁니다.

가장 좋은 방법은 기능 분기를 가능한 자주 개발자 분기에 병합하는 것이 일반적인 방법인 연속 통합입니다.이는 합병 통증의 오버헤드를 줄여줍니다.

가능한 한 자동화된 테스트에 의존하고 젠킨스의 유닛 테스트로 빌드가 자동으로 시작됩니다.개발자들이 변경 사항을 메인 브랜치에 병합하여 모든 작업을 수행하고 모든 코드에 대한 단위 테스트를 제공하도록 합니다.

테스트 담당자/QA는 코드 검토에 참여하고, 유닛 테스트를 점검하고, 기능이 완료되면 자동 통합 테스트를 작성하여 회귀 분석 스위트에 추가할 수 있습니다.

자세한 내용은 이 링크를 참조하십시오.

우리는 "금", "은", 그리고 "동"이라고 부르는 것을 사용합니다.이를 prod, staging, qa라고 할 수 있습니다.

저는 이것을 멜팅팟 모델이라고 부릅니다.비즈니스 측면에서 QA에 대한 요구사항은 기술적 요구사항과 비교하여 이해하기 어려울 수 있기 때문에 QA에 대한 요구사항이 매우 높기 때문에 NAT에 적합합니다.

버그 또는 기능을 테스트할 준비가 되면 "bronze"로 이동합니다.그러면 코드를 사전 빌드된 환경으로 푸시하는 젠킨스 빌드가 트리거됩니다.우리의 테스터들(참고로 슈퍼 기술자가 아닌)은 링크를 클릭만 할 뿐 소스 제어에는 관심이 없습니다.이 빌드는 테스트 등도 실행합니다.테스트(단위, 통합, 셀레늄)가 실패할 경우 이 빌드에서 코드를 테스트\qa 환경에 실제로 푸시했습니다.별도의 시스템에서 테스트할 경우(리드라고 함) QA 환경에 변경사항이 적용되지 않도록 방지할 수 있습니다.

처음에는 이 기능들 사이에 많은 충돌이 발생할 것이라는 우려가 있었습니다.기능 X가 기능 Y가 손상된 것처럼 보이지만 충분히 자주 발생하지 않으며 실제로 도움이 됩니다.이는 변화의 맥락을 벗어난 광범위한 테스트 범위를 확보하는 데 도움이 됩니다.많은 경우 운이 좋게도 당신의 변화가 병렬 개발에 어떻게 영향을 미치는지 알게 될 것입니다.

QA를 통과하면 기능을 "실버" 또는 스테이징으로 이동합니다.빌드가 실행되고 테스트가 다시 실행됩니다.매주 이러한 변경 사항을 "골드" 또는 프로드 트리에 적용한 다음 프로덕션 시스템에 배포합니다.

개발자들은 골드 트리에서 변경을 시작합니다.기술적으로 당신은 곧 그것들이 올라갈 것이기 때문에 준비 단계부터 시작할 수 있습니다.

긴급 수정 사항은 금 트리에 직접 저장됩니다.변경이 간단하고 QA하기 어려운 경우에는 실버로 바로 이동하여 테스트 트리로 이동할 수 있습니다.

출시 후에는 모든 것을 동기화하기 위해 골드(prod)를 브론즈(테스트)로 변경합니다.

준비 폴더에 밀어 넣기 전에 기본값을 다시 지정할 수 있습니다.우리는 테스트 트리를 때때로 청소하는 것이 청결을 유지한다는 것을 발견했습니다.특히 개발자가 떠난 경우 테스트 트리에서 기능이 삭제되는 경우가 있습니다.

대규모 다중 개발자 기능의 경우 별도의 공유 저장소를 생성하지만, 준비가 완료되면 동일하게 테스트 트리에 병합합니다.QA에서 문제가 발생하는 경우가 많기 때문에 변경사항 집합을 격리하여 스테이징 트리에 추가한 다음 병합/소멸할 수 있도록 하는 것이 중요합니다.

"베이킹"은 또한 좋은 부작용입니다.당신이 근본적인 변화를 가지고 있다면 그것을 위한 좋은 장소가 있습니다.

또한 이전 릴리스는 유지 관리하지 않습니다.현재 버전이 항상 유일한 버전입니다.그럼에도 불구하고, 당신은 아마도 당신의 테스터나 커뮤니티가 다양한 기여자들이 어떻게 상호작용하는지 볼 수 있는 마스터 베이킹 트리를 가질 수 있을 것입니다.

우리 회사에서는 애자일 개발을 사용할 수 없고 사업별로 변경할 때마다 승인이 필요하기 때문에 많은 문제가 발생합니다.

GIT와의 협력을 위한 우리의 접근 방식은 다음과 같습니다.

우리는 "Git Flow"를 회사에 구현했습니다.우리는 JIRA를 사용하고 승인된 JIRA 티켓만 생산에 가야 합니다.테스트 승인을 위해 별도의 테스트 분기를 생성하여 이를 확장했습니다.

JIRA 티켓을 처리하는 단계는 다음과 같습니다.

1. 개발 분기에서 새 분기 만들기
2. 피쳐 분기에서 코드 변경 수행
3. Feature에서 Test/QA 분기에 대한 변경 내용 끌어오기
4. 비즈니스 승인 후 기능 분기에서 개발로 변경합니다.
5. 릴리스에서 개발이 자주 진행되고 마지막으로 마스터 브랜치가 실행됩니다.

각 요청을 고유한 기능으로 분할하면 승인된 변경 사항만 운영 환경에 적용됩니다.

전체 프로세스는 다음과 같습니다.

저는 수동 테스트에만 의존하지 않을 것입니다.Jenkins와 함께 각 기능 분기의 테스트를 자동화할 것입니다.모든 브라우저에 대해 Linux 및 Windows에서 Jenkins 테스트를 실행하도록 VMWare 랩을 설정했습니다.이것은 정말 멋진 크로스 브라우저, 크로스 플랫폼 테스트 솔루션입니다.Selenium Webdriver와의 기능/통합을 테스트합니다.내 셀레늄 테스트는 Rspec에서 실행됩니다.Windows에서 jRuby에 의해 로딩되도록 특별히 작성했습니다.저는 전통적인 단위 테스트는 Rspec에서, 자바스크립트 테스트는 Jasmine에서 진행하고 있습니다.저는 Phantom JS로 헤드리스 테스트를 설정했습니다.

언급URL : https://stackoverflow.com/questions/18371741/git-branching-strategy-integated-with-testing-qa-process