이 프로세스는 이슈 트래커 또는 프로젝트 관리 시스템의 작업으로 시작됩니다: Jira, 버그질라, 맨티스, 온타임 또는 자체 사내 솔루션. 여기서 핵심은 모든 작업에는 반드시 연관된 작업이 있어야 한다는 것입니다. 새로운 기능의 일부이든 버그 수정이든 상관없이 작업을 만드세요.

그런 다음 해당 작업에 대한 브랜치를 만듭니다.

간단한 브랜치 이름 지정 규칙을 사용하는 것이 좋습니다: 이슈 트래커에서 접두사(예제에서는 "작업") 뒤에 작업 번호를 입력합니다. 이렇게 하면 변경 사항을 완벽하게 추적할 수 있습니다.

작업 브랜치에서 작업하고 필요한 만큼 체크인을 하세요. 댓글의 각 단계를 설명하여 검토자가 명확하게 이해할 수 있도록 하세요.

작업이 완료되면 브랜치의 "상태" 속성을 "해결됨"으로 설정합니다.

또는 이슈 트래커에서 완료된 것으로 표시할 수도 있습니다. 이는 모두 특정 도구 세트와 실제로 워크플로를 구현하는 방식에 따라 다릅니다.

작업을 완료로 표시하면 동료가 검토할 수 있습니다.

이제 검토자가 변경 사항을 살펴보고 코딩 스타일에서 버그, 오류, 불일치 또는 변경해야 할 디자인 측면을 발견할 수 있는지 살펴볼 차례입니다. 그렇다면 작업이 다시 열리고 주기가 다시 시작됩니다.

유효성 검사는 선택적 단계입니다.

어떤 팀은 작업을 '검증'하고, 다른 팀원은 새로운 기능이나 변경 사항이 합당한지 확인하기 위해 간단한 탐색 테스트를 수행합니다. 버그를 찾는 것이 아니라(자동화된 테스트가 이를 처리합니다) 고객의 관점에서 변경 사항을 살펴봅니다. 상태는 속성에서 '유효성 검사됨'으로 설정할 수 있습니다.

특정 속성 집합이 있는 모든 브랜치를 모니터링하도록 지속적 통합(CI) 시스템을 구성하세요. 브랜치는 지정된 상태(이 경우 "유효성 검사 완료")에 도달한 경우에만 CI 시스템에서 고려됩니다.

작업이 검토/검증되면 작업 브랜치는 메인에 병합되기 전에 자동으로 테스트됩니다.

테스트 스위트가 병합을 통과하면 확인을 거쳐 CI 시스템에 제출되어 빌드 및 테스트가 진행됩니다. 이 프로세스는 빌드가 중단되는 것을 방지하는 데 도움이 됩니다. 실패하면 프로세스가 다시 시작되고 충돌을 해결하기 위해 메인에서 다시 베이스해야 합니다.

테스트가 통과되면 병합이 체크인되고 이제 브랜치를 제공할 준비가 된 것입니다. 이제 상태가 "병합됨"으로 설정된 것을 확인할 수 있습니다.

새 릴리스를 배포할 준비가 되면 메인에 있는 새 변경 집합에 해당 레이블이 지정되고 소프트웨어가 프로덕션에 배포됩니다.

모든 새 작업이 이 주기를 통과할 때마다 새 릴리스를 받거나 몇 가지 작업을 그룹화할 수 있습니다. 연속 배포를 실행할 때는 모든 작업을 프로덕션에 배포하는 것이 가장 논리적인 워크플로입니다.

Unity 버전 관리에서 자동화된 테스트 및 병합 단계는 Jenkins, Bamboo 또는 Unity 클라우드 빌드 등 선택한 CI 툴용 플러그인을 사용하여 구성할 수 있습니다 .

이 단계는 Unity 버전 관리의 병합 봇 기능을 사용하여 오케스트레이션할 수도 있습니다. 병합 봇은 브랜치를 병합하고 빌드를 트리거하여 작동하는지 확인할 수 있습니다. 빌드가 양호한 경우에만 병합이 확인되므로 빌드가 깨지는 것을 방지할 수 있습니다.

저희는 접두사 + 작업 번호라는 이름 지정 규칙을 고수하고 있습니다. 예를 들어 브랜치의 이름은 task1213, task1209, task1221이 될 수 있습니다. 접두사는 '작업'이고 숫자는 연결된 이슈 트래커의 실제 작업 번호를 나타냅니다.

스크린샷에는 브랜치 탐색기가 이슈 트래커에서 번호를 검색하므로 번호와 함께 각 브랜치에 대한 설명도 표시됩니다. "브랜치 작업 정보 표시"를 선택하여 브랜치 설명을 볼 수도 있습니다.

스크럼 규칙에 따르면 작업 시간은 16시간을 넘지 않아야 합니다. 이렇게 하면 프로젝트 일정을 관리할 수 있습니다.

작업 브랜치는 신속하게 종료해야 합니다. 이상적으로는 단 몇 시간 안에 끝낼 수 있는 작은 작업이 많아야 합니다. 이 구조는 프로젝트 리듬을 유지하고 지속적인 배포를 용이하게 합니다. 예를 들어 일주일에 걸친 대규모 작업은 주기를 멈추게 합니다.

명심해야 할 한 가지 위험 신호가 있습니다: "마체테 컷" 작업을 만들지 마세요. 작업을 더 작은 조각으로 잘라야 하는 경우, 작업이 여전히 독립적으로 의미가 있고 독립적으로 배포할 수 있는지 확인하세요.

태스크 브랜치 워크플로는 팀 전체의 동의를 얻어야만 성공할 수 있습니다.

다른 데브옵스 프로세스와 마찬가지로 이 워크플로에는 문화적인 요소가 있습니다. 작업 브랜치는 진행 상황을 공개적으로 소통하고 사일로를 피하기 위한 것입니다. 워크플로 또는 특정 작업 방식을 의무화하기 전에 먼저 조정을 추진해야 합니다. 팀원들이 더 큰 작업으로 더 오래 고생하는 것보다 큰 작업의 작은 부분을 오늘 마무리하는 것이 어떤 이점이 있는지 이해하도록 도와주세요.

스스로(또는 팀원에게) 물어보세요: task1213에서 방금 완료한 코드가 task1209를 시작하기 위해 꼭 필요한가요?

작업은 생각보다 훨씬 더 독립적인 경향이 있습니다. 예, 같은 주제에 관한 것일 수 있지만 정확히 같은 코드를 건드릴 필요는 없습니다. 새로운 내용을 추가하기만 하면 병합이 알아서 처리할 것입니다.

위의 예에서 1213과 1209가 작업이 아닌 버그 수정이라고 가정해 보겠습니다. 한 쪽이 다른 쪽에 의존하는 것을 원치 않으실 겁니다. 가능한 한 빨리 메인에 노출되어 출시되기를 원합니다. 같은 코드를 건드리더라도 서로 다른 수정 사항입니다.

모든 체크인은 검토자가 여러분의 생각과 과정을 따라가면서 작업을 어떻게 해결했는지 이해할 수 있도록 도와야 합니다.

체크인 댓글에 세부 정보를 남기면 검토자가 전체 지점을 확인할 필요가 없으므로 도움이 됩니다. 대신 변경 집합별로 변경 집합이 달라집니다. 그리고 작업의 각 단계를 명확히 하기 위해 미리 녹음된 설명을 따라 진행하게 됩니다. 100개 이상의 수정된 파일로 이루어진 굵은 목록을 보는 일은 없을 것입니다. 대신 단계별로 진행합니다.

모든 작업 브랜치는 완료되면 통합할 준비가 되어 있어야 합니다. 변경 사항이 취약하거나 제품이 어색하게 작동하는 경우 작업을 완료로 설정해서는 안 됩니다.

이는 자동화의 이점을 위해 지불하는 작은 대가입니다. 팀은 "완료"의 정의, 즉 "프로덕션 준비 완료"에 대해 의견을 조율해야 합니다. 그 대신, 작업을 프로덕션으로 옮기는 것이 쉽고 완전 자동화되어 있으며 새벽 2시에 소방 훈련으로 이어지지 않으므로 안심하고 작업을 진행할 수 있습니다.

기능 토글이란 무엇인가요? 이는 지속적인 배포를 위해 매우 중요합니다. 이 소프트웨어 개발 기법을 사용하면 기능을 완성하고 출시할 준비가 되기 전에 테스트할 수 있습니다.

기능 토글은 런타임 중에 기능을 숨기거나 활성화 또는 비활성화할 수 있습니다. 개발팀, 소수의 얼리어답터 또는 모든 사용자에게만 기능을 사용하도록 설정할 수 있습니다. 예를 들어 개발자는 개발 중에 테스트용으로 기능을 활성화하고 다른 사용자에게는 비활성화할 수 있습니다.

예를 들어 보겠습니다. 큰 기능을 7개 부분으로 나누어 작업으로 변환하고 작업 브랜치를 사용하여 구현할 수 있습니다. 아무것도 준비되지 않은 상태에서 어떻게 파트 4를 배포할 수 있나요?

파트 4는 메인 브랜치에 병합할 수 있으며 기능 토글을 사용하여 숨긴 상태로 배포할 수도 있습니다.

숨겨져 있다고 해서 새 코드가 릴리스 전에 테스트를 건너뛰는 것은 아닙니다. 전체 기능을 활성화할 준비가 되면 개별 부품은 이미 여러 번 테스트를 거쳤을 것입니다. 마지막 조각의 통합은 빅뱅 병합을 트리거하지 않으며, 단지 작은 부분이 메인으로 이동하는 것일 뿐입니다.