우리는 동일한 git 저장소를 사용하여 여러 프로젝트를 작업하는 큰 팀 (10-12 개발자 및 4 qa)입니다. 스프링 부트 기반 백엔드 웹 서비스입니다. 우리는 좋은 자식 분기 및 배포 전략을 찾고 있습니다. 우리는 또한 우리의 기능이 예상대로 작동하는지 확인하는 qa 팀을 가지고 있습니다 (버그가 어느 정도 무료입니다).
몇 가지 기사를 읽은 후 Gitflow 모델이 우리에게 잘 작동 한다는 느낌이 들었 습니다. 여기 내 질문이 온다.
품질 관리팀은 기능을 어디에서 테스트해야합니까?
다른 사람에게 어떤 접근 방식이 잘 작동했는지 궁금합니다.
답변:
품질 관리는 아마도 두 번 테스트해야합니다.
첫 번째 테스트는 특정 변경 사항에 대한 것이며 기능 분기에서 수행해야합니다. 이를 통해 품질 보증팀은 특정 변경 사항을 테스트하고 특정 변경 사항이 지정된대로 완료되고 예상대로 작동하는지 확인할 수 있습니다. 또한 2 차 테스트에 대한 초기 미리보기를 제공하는데, 이는 실제로 QA에 중요합니다.
다양한 규제 환경에서 배경을 바탕으로 두 번째 테스트는 릴리스에 해당하는 개발 브랜치의 태그 또는 릴리스 브랜치 또는 마스터 브랜치에서 수행해야합니다. 출시 전에 QA는 배포하기 전에 배포 될 전체 코드를 테스트해야하며 QA에서 테스트 한 모든 것이 프로덕션에 배포 된 것과 정확히 동일하다는 것을 주장 할 수 있어야합니다. 코드 동결 후 태그가 릴리스 브랜치에 적용되고 QA가이를 테스트하는 것이 좋습니다. 개발 브랜치에서 변경 사항을 확인하고 스팟을 확인한 다음 릴리스 브랜치의 새 태그에서 다시 테스트했습니다. 릴리스 브랜치의 이러한 태그는 릴리스 후보에 해당합니다.
나는 여기에 몇 가지 가정을하고 있습니다. 첫째, 개발자 기반의 테스트 범위가 다소 괜찮습니다. 이상적으로는 분기의 코드를 QA로 보내기 전에 개발자가 실행하고 수행하는 자동화 된 단위 및 통합 테스트입니다. 또한 개발자는 UI를 중심으로 탐색 테스트를 수행하여 QA 테스트 직전에 상황이 표시되도록 할 수도 있습니다. 둘째, 기능에 따라 충분한 QA 시간을 보장하기 위해 통합 변경 사항을 계획하기 위해 개발과 QA간에 적절한 조정이 있습니다.
좋은 질문입니다. 나는 이것에 대한 '공식적인'정답이 없다고 생각합니다. 테스트 속도에 따라 다릅니다.
근본적인 문제는 각 병합, 컴파일 또는 배포가 잠재적으로 버그를 생성 할 수 있다는 것입니다. 테스트하는 체인을 더 '업'할수록 버그에 대해 더 빨리 알 수있을뿐만 아니라 다시 테스트해야하는 횟수가 늘어납니다.
고객이 사용중인 소프트웨어를 테스트했음을 확인하려면 고객 트래픽 (웹 앱 가정)이 파란색 / 녹색 배포 패턴을 통해 해당 서버로 라우팅되기 전에 실제 배포를 테스트해야합니다.
그러나 분명히 이것은 코드를 처음 확인한 날이 늦었습니다.
qa env에서 릴리스 브랜치를 테스트하면 위험을 감수하고 연기 테스트로 인한 라이브 테스트를 줄일 수 있습니다. 릴리스 브랜치에 버그 수정을 적용합니다. 그러나 릴리스를 작성하기 전에 기능이 완전한지 여부를 평가할 수 없습니다
개발을 테스트하면 미니 버그 수정 기능 분기가 제공됩니다. 기능은 평가하기 전에 여전히 병합되며 다음 릴리스의 기능은 현재 릴리스 테스트와 충돌 할 수 있습니다.
기능 분기를 테스트하는 경우 백만 개의 환경이 필요하며 병합 순서를 테스트하고 사인 오프를 테스트해야합니다. 많은 재시험.
내 경험으로는 다음을 권장합니다.
개발자 컴퓨터의 기능 분기를 빠르게 테스트합니다. 기능이 완전하고 테스터 / 개발자는 요구 사항의 의미에 동의해야합니다.
QA 서버에 배포 된 개발 지점의 일상적인 테스트 / 자동 테스트 모든 기능을 함께 테스트하고 릴리스 준비가되었을 때 말할 수 있습니다.
모든 기능이 있지만 테스트가 완료되지 않은 경우. 예를 들어 스프린트가 완료되었습니다. 릴리스 브랜치를 만들고 두 번째 QA 환경에 배포하십시오. 이를 통해 릴리스 1의 버그 수정 / 테스트가 릴리스 2의 기능과 동시에 계속 될 수 있습니다.
(스크럼 애호가들은 스프린트 2에 버그 수정 만 넣어야하지만 실제로는 가능하도록해야합니다)
전환하기 전에 라이브 녹색 / 파란색 배치에 대한 연기 테스트. 개발 중에 아무도 찾지 못하는 구성 / 환경 오류를 선택하므로 이는 매우 중요합니다.
나는 Thomas Owens에 동의합니다. 아마도 두 번 테스트해야합니다. 기능 브랜치는 병합되기 전에 한 번, 메인 브랜치에서 한 번 릴리스 한 후에 해제하십시오.
실제로, 나는 그 워크 플로를 너무 좋아해서 각각의 고유 한 테스트 URL을 가진 각 풀 요청에 대해 일회용 버전의 앱을 자동으로 빌드하고 실행하는 Topico 도구를 만들었습니다 . 이를 통해 QA 팀은 자체 기계에 어떤 종류의 동적 테스트 환경을 설정할 필요없이 기능 지점을 개별적으로 테스트 할 수 있습니다.
이 접근 방식은 사람의 테스트를 통과 한 코드 만 기본 지점에 도달하여 무결성을 유지한다는 의미입니다.
나는 이것을 두 회사에서 소개했고 우리의 출시주기에 많은 도움이되었습니다. 이제 릴리스를 정확하게 예약 할 수 있으며 다음 릴리스로 만들 가능성과 향후 릴리스를 기다려야 할 사항을 더 잘 이해하고 있습니다. 그것은 당신에게 더 많은 자신감을줍니다.