기능이 테스트 준비를 위해 점점 더 커질수록 문제가 발생하기 시작하지만, 모든 것이 테스트되고 승인 된 새로운 기능이 테스트 준비에 들어갑니다.

이는 테스트 된 기능과 테스트되지 않은 기능이 결합되어 있기 때문에 프로덕션 환경에 거의 도달 할 수없는 환경을 만들고 있습니다. 나는 이것이 일반적인 문제라고 확신하지만 아직 우리에게 좋은 자원을 찾지 못했습니다.

일부 세부 사항 :

• BitBucket에서 GIT
• Azure에 스크립트 배포를위한 Jenkins

내가 기대하는 것은 환경을 통해 이동하면서 기능을 분리하고 준비가 된 것을 밀어내는 방법입니다.

여기에 몇 가지 문제가있는 것 같습니다.

1. 특정 릴리스의 기능 식별

이것은 프로젝트 관리 문제이며 조정 문제입니다. 윌 이 기능은 동시에, 이전에 출시 된, 또는이 이후에 할 다른 기능? 릴리스가 한 번에 하나의 기능을 수행하려면 해당 기능을 식별하십시오. 기능이 릴리스로 그룹화 될 경우 그룹화가 무엇인지 파악하고 개발자 및 의사 결정자에게 이를 적용하십시오 . 문제 추적 또는 발권 시스템을 사용하여 릴리스에 태그를 지정하십시오. 특정 릴리스의 기능 중 하나라도 문제가없는 경우 모든 기능이 있음을 분명히하십시오.

2. 분기 전략

Git-flow 는 이와 같은 문제에 대한 쉬운 대답이며, 사람들은 git-flow의 변형을 사용합니다. 나는 그것이 모든 문제에 대한 포괄적이라고 말하지는 않지만 많은 도움이됩니다.

비결정론 적 출시 전략에서 문제가 발생하는 것으로 보입니다. 기능은 분산 산포로 승인되었으며 오래 전에 개발을 시작한 것이 더 최근에 시작된 무언가-도약-개구리 기능 이후에 릴리스 될 수 있습니다.

수명이 긴 기능 분기 또는 동시 릴리스 분기는 아마도 이러한 종류의 문제에 가장 적합한 답변 일 것입니다. 마스터 에서 최신 지사로 최신 정보 를 병합 (또는 편안한 경우 리베이스)하십시오 . 이미 존재하는 기능 만 병합 하도록주의하십시오 . 그렇지 않으면 현재 발생한 문제 (한 지점에 너무 많은 혼합 된 기능)가 발생합니다.

"핫픽스"또는 "버그 픽스"분기는이 프로세스의 필수 부분입니다. QA주기가 짧은 소규모 일회성 수정에 사용하십시오.

설명에서 공식적인 '개발'브랜치를 유지 하지 않는 것이 좋습니다 . 오히려, 모든 기능을 마스터에서 분기하고 릴리스가 식별되면 병합 된 릴리스 분기를 작성하십시오.

3. 환경

프로덕션 == 마스터를 제외하고 git 브랜치를 환경과 일치시키지 마십시오. '개발'지점은 고장난 것으로 가정해야합니다. 릴리스 브랜치는 QA 환경이든 스테이징 환경이든 테스트 환경으로 푸시됩니다. 필요한 경우 특정 기능 분기를 환경으로 푸시하십시오.

별도로 릴리스해야하지만 동시에 테스트중인 기능 분기가 둘 이상있는 경우 ..... ¯ \ _ (ツ) _ / ¯ .... 다른 서버를 가동 하시겠습니까? 어쩌면 그것들을 함께 버림 지점으로 병합 할 수도 있습니다. 원래 브랜치에 대한 수정 / 변경 사항을 커밋하고 다시 버림 지점으로 다시 병합하십시오. 개별 릴리스 지점에서 최종 승인 및 UAT를 수행합니다.

분기에서 승인되지 않은 기능 제거

이것은 의심 할 여지없이 시도하고 행해야 할 가장 고통스러운 일이기 때문에 위의 생각들이 피하려고하는 것입니다. 운이 좋으면 병합 커밋을 사용하여 기능이 개발 또는 테스트 브랜치에 병합되었습니다. 운이 좋지 않으면 개발자는 개발 / 테스트 지점에 직접 헌신했습니다.

어느 쪽이든, 당신이 출시를 준비하고 승인되지 않은 변경 사항이있는 경우, 당신은 할 수 힘내를 사용해야합니다 밖으로 다시 릴리스 지점에서 그 승인되지 않은 커밋; 가장 좋은 아이디어는 릴리스 를 테스트 하기 전에 수행하는 것입니다.

행운을 빌어 요.

릴리스 브랜치 사용 중지 아이디어가 있습니다. 대신 기능 토글 에서 빌드를 시작 하고 구성을 통해 관리하십시오. 이렇게하면 항상 피처 브랜치를 마스터에 병합 할 수 있으며 테스트중인 버전이나 제품 버전에 대한 의문은 없어야합니다. 환경에서 활성화 된 기능 / 구현에 대한 질문이있는 경우 구성 파일을 확인하십시오.

이것은 테스트와 프로덕션 사이의 간단한 조정 문제 여야합니다. Git에서 기능 분기를 사용하는 경우 테스트주기 중에 완료된 기능 분기를 테스트로 푸시하는 것을 중지하고 테스트가 완료되면 다시 시작하십시오.

이보다 더 나은 제어가 필요한 경우 테스트를 개발 서버와 승인 테스트 서버로 분리하고 테스트 팀과 함께 승인 테스트 서버로 푸시 될 분기를 조정하십시오. 그러면 승인 테스트에서 프로덕션으로 최종 배포를 시작하는 사람이 누군가가 될 수 있습니다.

일을 쌓다

이것은 내 경험에서 보편적 인 문제입니다. 나는 그것을 해결 :

• 제품 소유자의 강력한 기능 릴리스 관리
• 브랜치가 병합 될 때 삭제되도록하십시오
• 진행중인 작업 제한 (Jira의 열 제한)
• 버그와 기능을 모두 해결하는 오래된 티켓에 대한 분기 별 검토
• 문제의 구성 요소를 논의하기위한 회고
• 모든 사람의 코드 검토에 대한 지속적인 격려
• 오랜 티켓과 문제를 해결하기위한 페어링 기회
• 오래된 티켓을 검토하고 정리하기위한 분기 별 회의
• 개발자, 제품 및 QA / QE가 긴밀하게 협력 할 수있는 팀 방식
• 새로운 제품 기능과 백 로그를 명백하게하는 좋은보고 및 도구
• 세션을 검토하여 오래된 브랜치를 통과하고 삭제

지점

해당 프로세스를 제어하려면 몇 가지 분기가 필요합니다.

• 특징 :이 지점은 마스터에서 태어났습니다. 일부 프로젝트 관리 응용 프로그램을 사용하여 일부 기능으로 각 기능 분기를 식별하십시오. 예를 들어, TRAC를 사용하는 경우 : 1234-user-crud, 1235-bug-delete-catalog등의 분기가 완료되면 종료됩니다 . 작업 번호로 커밋도 식별하면 병합에 문제가있는 경우 많은 도움이됩니다.
• 테스트 : 수행 된 모든 기능 분기가 테스트 분기에 병합됩니다. 당신은 몇 가지 기능 지점에 테스트 지점을 병합하지 프로덕션 (마스터)에없는 다른 기능에서 코드를 원하지 않기 때문에. release브랜치 에도 동일합니다 .
• 릴리스 : 프로덕션에서 테스트 할 수있는 기능을 결정할 때이 분기에서이 분기 (다시 ...)를 병합합니다. 이 병합으로 인해 새로운 문제가 발생할 수 있으므로 모든 기능을 다시 테스트해야합니다. 릴리스가 테스트되고 완료되면이 분기를 마스터로 병합하고 버전에 대한 마스터에서 태그를 작성합니다.
• master : 프로덕션 코드 만 포함합니다.

자식 흐름을 참조하십시오 :

                              |FEAT_2|
                                  |
                             .---C06<-------.---------.
                            /                \         \
                           /   |FEAT_1|        \         \
                          /       |            \         \
                         /    .--C07<--.--------\---------\---------.
                        /    /          \        \  |TEST| \         \
                       /    /            \        \    |    \         \
                      /    /        .-----`--C09<--`--C10    \         \ |RELEASE|
                     /    /        /                          \         \    |
    <v4.6.0>        /    /        /                       .----`--C11<---`--C12<--.
       |           /    /        /                       /                         \
C01<--C02<--C04<--´----´--------´-----------------------´---------------------------`--C13
 |           |                                                                          |
<v4.5.0>  <v4.6.1>                                                                   |MASTER|
                                                                                        |
                                                                                     <v4.7.0>

환경

매우 간단합니다 :

• 테스트 :이 환경은 테스트 브랜치를 사용합니다.
• release :이 환경은 실제 릴리스 브랜치를 사용합니다.

개발자는 자신의 데이터베이스를 사용하여 자신의 컴퓨터에서 작업합니다. 라이센스, 데이터베이스 크기 등으로 인해 각 개발자가 개별 데이터베이스를 보유 할 수 없다면 개발자간에 데이터베이스를 공유하는 데 많은 문제점이 있습니다. 분기는 여전히 데이터베이스에서이 열 / 테이블로 계산됩니다.

문제

이 프로세스에서 가장 큰 문제는 병합입니다.

test와 에서 동일한 병합을 다시 만들어야합니다 release. 클래스 삭제, 이동 / 이름 바꾸기 메소드 등과 같이 코드에 좋은 리 팩터가 작성되면 고통 스러울 수 있습니다.test (또는 release) 브랜치에서 피처 브랜치로 코드를 가져올 수 없으므로 병합 커밋은 test(또는 release). 에 : 그래서, 당신은 아마 미래에 각 병합에 다른 코드를 생성하고, 두 개의 서로 다른 지점에서 같은 충돌을 해결 결국, 당신은 테스트 팀이 두 번 기능을 테스트 할 필요가 있음을 발견 할 것입니다 test및 release지점, 각 병합 때문에 다른 버그가 발생할 수 있습니다.

또 다른 문제는 test지점입니다. master오래된 분기 (또는 오래된 병합, 삭제 된 병합 된 분기)가 새 코드에 많은 문제를 일으킬 수 있기 때문에 때때로이 분기를 "재활용"해야합니다 (삭제 및에서 새 분기 만들기 ). 에있는 것과 많이 다릅니다 master. 이 시점에서에 병합하려는 분기를 제어해야합니다 test.

가장 좋은 솔루션은 비즈니스 팀이 다음 버전에서 무엇을 제공해야하는지 알고 모든 사람이 고유 한 지점 (개발 지점)에서 일하는 것입니다. 원하는 경우 언제든지 다음 버전에서 원하는 "완료"기능을 선택할 가능성이 있지만 (이것이 시나리오라고 생각합니다), 개발자에게는 악몽입니다. 테스트 팀.

통합 브랜치에서 프로덕션 브랜치로 변경 사항을 병합하는 것처럼 들립니다. IMHO는 언급 한 이유로 정확하게 권장되지 않습니다. 특정 릴리스의 프로덕션 분기가 기본 통합 분기에서 가져 오면 통합 분기는 언제든지 분기 될 수 있습니다 (결국 다음 릴리스로 진화해야 함). 통합 분기에서 현재 릴리스 분기로 병합하면 해당 릴리스와 호환되지 않는 변경이 발생할 수 있습니다.

적절한 절차는 다음과 같습니다.

• 원하는 품질 수준에 충분히 근접한 것으로 판단되는 경우에만 통합 브랜치에서 생산 브랜치를 가져 오면 소수의 변경 만 릴리스를 완료 할 것으로 예상됩니다. 다시 말해 생산 브랜치를 끌어 오기 전에 통합 브랜치에서 피처 완료를 지속적으로 평가해야합니다.
• 생산 지점을 가져온 후에는 체리로 선택한 변경 사항 만 가져와 독립형 / 점수 수정으로 처리됩니다. 즉, 실제로는 예상대로 작동하는지 확인합니다 (한 지점에서 변경 작업이 반드시 작동한다는 의미는 아닙니다) 다른 지점에서).

개인적으로 이는 툴링 문제 이상의 프로세스 문제 일 수 있습니다. 여기에 제안 할 몇 가지 사항이 있습니다.

• 별도의 Dev 및 QA 그룹이 있는지 확실하지 않습니다. 그렇다면, Dev와 QA 모두 스프린트 계획 및 평가 회의에 참여해야합니다. 이전 회사 중 하나에서 우리는 스토리를 할당 한 스토리 포인트 수가 개발 및 테스트 노력을 모두 설명하는지 확인했습니다. 이론적으로 개발자와 QA 노력에 대한 두 가지 별도의 추정치를 가질 수 있지만 두 가지를 모두 포함하는 추정치에 필요한 두 가지 방법이 있습니다. 스토리에 필요한 시간은 실제로 전달하는 데 필요한 시간입니다. 별도의 QA 그룹이 없더라도 추정에 테스트 노력을 포함해야합니다.
• 위와 비슷한 맥락에서 특정 스프린트에 포함 할 스토리 수에 미리 동의하십시오. 수락 이야기 점의 수는 개발자가 자신의 스프린트에서 완료 할 수있는 금액을 기반으로 하고 QA가 단거리 경주에서 테스트 할 수있는 항목의 수. (물론 QA 스프린트는 개발자 스프린트보다 뒤떨어져 있다고 가정하지만 프로세스에 맞게 조정할 수 있습니다). 개발자가 200 스토리 포인트를 완료 할 수 있지만 QA가 150 스토리 포인트 만 완료 할 수있는 경우, 작업이 "완료"되기 전에 150 스토리 포인트 만 수행 할 수 있으며 설명과 같은 경우가됩니다. (이와 같은 경우로드 블록의 원인을 조사하여 완화하려고 할 수 있습니다).
• 현재 QA에있는 모든 것이 테스트 되고 전달 될 때까지 아무도 QA에 아무것도 푸시하지 않습니다 .
• 완전한 기능은 테스트 및 제공되는 기능입니다. 배송되지 않으면 완료되지 않습니다.
• 분명히, 일정 종류의 일정에 따라이 작업을 수행하려고합니다. Continuous Integration and Agile의 전체 아이디어 중 하나는 반복입니다. 정의에 따르면 반복에는 빈번한 전달이 수반됩니다. 빈번한 통합 및 제공은 각각의 위험을 최소화합니다.

솔직히 말하면, 가장 큰 것은 당신이 제공 할 때와 주어진 시간 내에 실제로 완전히 완료 할 수있는 작업의 수에 관한 훈련이라고 생각합니다.

요약하면 : 이전 기능을 테스트하고 제공 한 경우에만 QA에 제공합니다.

"모든 것이 테스트되고 승인 된"경우 테스트되고 프로덕션에 승인 된 것을 배포하십시오. 특정 커밋 일 수도 있고 Jenkins가 생성 한 특정 빌드 아티팩트 일 수도 있습니다.

동일한 분기에서 나중에 커밋이 아직 테스트되지 않았다는 것은 중요하지 않습니다.