민첩한 개발 배포 프로세스 품질 관리 및 비즈니스 소유자는 어디에서 테스트합니까?

9

최근 SVN 또는 GIT를 사용하는 다양한 웹 응용 프로그램 배포 프로세스에 대해 많이 읽었으며 현재 작업 위치를 배포하는 방법을 다시 설계했습니다.

다양한 애자일 방식과 마찬가지로 마스터 또는 트렁크에 투입된 모든 제품은 생산 준비가 완료된 것으로 가정합니다. GitHub와 Etsy ( http://codeascraft.etsy.com/2010/05/20/quantum-of-deployment/) 는이 기준에 따라 작동한다고 말합니다 (Etsy는 실제로 준비 환경이 있음).

이 프로세스는 모든 단위 테스트 및 CI 테스트가 실행되었다고 가정합니다. 로컬 및 CI에서 테스트를 실행 한 다음 트렁크에 커밋합니다. 따라서이 시점에서 코드는 기술적으로 적합합니다.

코드는 기술적으로는 정확하지만 사용자 / 기능 테스트는 특히 프런트 엔드 테스트와 관련하여 더 많은 버그를 발견 할 수 있습니다.

내 질문은 이것입니다. QA 및 비즈니스 소유자는 구현 한 기능 변경을 어디에서 테스트합니까? 트렁크를 커밋하기 전에 로컬 개발 시스템 또는 QA / 스테이징 시스템에서?

트렁크를 사용하는 준비 시스템이 있고 트렁크에 커밋 된 모든 코드가 프로덕션 준비가되었다고 가정하면 ... 어느 시점에서 코드가 서명되고 기술 및 비즈니스 모두에서 프로덕션에 들어가기에 좋습니다. 원근법? 스테이징 머신이 하나만 있고 많은 개발자가 코드를 품질 보증해야하는 경우 많은 개발자 변경 사항이 사인 오프를 기다리는 동안 트렁크에서 어떻게 배치 할 수 있습니까?

다른 사람들이 어떻게 접근했는지 듣고 싶습니까?

— 바자
소스

6

더 좋든 나쁘 든 나는 일반적으로 지점 기반에 대해 테스트가 수행되고 비즈니스 사인 오프가 체크 포인트가 배포 메인에 병합되는 곳에서 수행되는 것을 볼 수 있습니다.

나는 "배포 된"브랜치가있는 "메인"의 개발 또는 "배포 된"의 메인을 가진 개발 "피처"브랜치 둘 다를 수행하는 것을 보았다.

워크 플로는 다음과 같이 보입니다.

무언가를 코딩하다
로컬 테스트를 실행
작업 지점에 체크인
(선택 사항) 빌드 서버 빌드 개미 테스트
품질 관리 / 비즈니스 테스트
버그 수정 (루프 맨 위로)
지점을 배치하기 위해 병합
전개하다

일부 사람들은 단일 지점에서 작업하지만 수동 테스트를 수행하려는 경우 어려움을 겪습니다. 내가 한 대부분의 사람들은 단일 트렁크에서 작동하는 커밋에 배포 할 수있는 작업이 작은 작업을 수행하거나 많은 양의 자동 테스트를 수행한다고 가정하거나이 대화에서 "배포"를 고려한다고 가정했습니다. 테스트 서버를 구축해야하며 테스트 서버와 프로덕션간에 발생하는 QA 프로세스는 별도로 처리됩니다.

— 계산서
소스

고마워 빌. 우리는 개발자가 지속적으로 사이트에 대해 별도의 기능을 커밋하고 배포하는 환경에서 일합니다. 기능 분기에서 작업하는 경우 작업 분기를 체크인 한 후 QA / 비즈니스 테스트가 수행되는 위치는 어디입니까? 개발자가 지점에 커밋하는 QA 머신이 하나 뿐인 경우 QA 머신에서 각 개발자에 대해 별도의 애플리케이션 서버 인스턴스와 사이트가 설정되어 있지 않으면 실제로 한 번에 하나의 기능 만 테스트 할 수 있습니다. 트렁크에 커밋하기 전에 변경 사항을 개별적으로 테스트 할 수 있습니다.

— Bazza

이것에 대한 나의 경험에서 우리는 일반적으로 각 개발자마다 별도의 기능 분기를 만들지 않았으며 각 팀마다 하나 더 비슷하게 만들었고 여분의 개발자 컴퓨터 일지라도 각 직원에 대해 qa 호스트를 설정했습니다.

— Bill

의견을 부탁드립니다. 나에게 몇 가지 아이디어를 주었다.

— Bazza

2

동일한 기능 지점에서 자동 수락 테스트를 수행했습니다. 릴리스 후보를 만들 때 기능이 통과했는지 확인하기 위해 실행 한 자동 테스트가 포함됩니다. 또한 릴리스 후보를 테스트하십시오. 모든 것이 지나면, 당신은 마스터로 합병하여 그것을 홍보합니다.

이 프로세스에 대한 자세한 내용은 여기를 참조하십시오.

https://plus.google.com/109096274754593704906/posts/R4qkeyRadLR

의견도 확인하십시오.

도움이 되었기를 바랍니다,

아담

— 아디 미트 룩
소스

@Adam-감사합니다. 흥미로운 토론이있었습니다. 생각할 거리.

— Bazza

0

일반적으로 코드가 완성되기 전에 커밋을 기다리는 것은 버전 제어 시스템의 이점을 절반으로 가져 오는 것입니다. (많은 정교함이 없으면 VCS에 여러 번 체크인 할 수 없다면 내 작업을 되돌릴 수있는 방법이 없습니다!) 실제로 우리는 항상 사람들에게 체크인을 계속하도록 요청합니다 (SVN의 지점 내에서) 또는 GIT의 경우 로컬 커밋 일 수 있습니다). 실제로는 더 좋습니다.

그러나, 모든 곳에 지점 도착 나타납니다 수행하고 테스트 할 - 우리는이 릴리스 호출하고 다음 그것은 트렁크에 병합됩니다. 본질적으로, QA는 HEAD지점 에서 새로 점검하여 RC를 인증 할 수 있으며, Okey가 있으면 트렁크와 다시 병합됩니다.

따라서 기본적으로 태스크 브랜치 또는 개인 브랜치라는 개념을 사용하므로 사람들이 원하는만큼 체크인 할 수 있습니다. 동시에, 트렁크는 상대적입니다 무료로 어떤에서 깨진 체크인.

— 디판 메타
소스