작업 브랜치 워크플로 구현 방법

이 프로세스는 이슈 트래커 또는 프로젝트 관리 시스템의 작업으로 시작됩니다. Jira, Bugzilla, Mantis, OnTime 또는 자체 솔루션을 사용해 보세요. 여기서 핵심은 모든 작업에 연결된 작업이 있어야 한다는 것입니다. 새로운 기능의 일부이든 버그 수정이든 상관없이 해당 작업을 생성하세요.

그런 다음 해당 작업의 브랜치를 생성합니다.

간단한 브랜치 명명 규칙을 사용하는 것이 좋습니다. 이슈 트래커의 작업 번호를 따라 접두사(예시의 ‘task’)를 사용합니다. 따라서 변경 사항을 추적할 수 있습니다.

작업 브랜치를 작업하고 필요에 따라 체크인을 수행합니다. 각 단계를 주석에 설명하여 모든 리뷰어에게 명확성을 제공하세요.

작업이 완료되면 브랜치의 'status' 속성을 'resolved'로 설정합니다.

또는 이슈 트래커에서 완료된 상태로 표시할 수도 있습니다. 모든 것은 특정 툴 세트와 실제로 워크플로를 어떻게 구현할지에 따라 달라집니다.

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

이제는 변경 사항을 검토하여 코딩 스타일에서 버그나 오류, 불일치 또는 변경해야 할 디자인 요소를 발견할 수 있는지 확인해야 합니다. 그러면 작업이 다시 열리고 사이클이 재시작됩니다.

검증은 선택 사항입니다.

일부 팀은 작업을 '검증'합니다. 다른 팀원은 새로운 기능이나 변경 사항이 적절한지 확인하기 위해 짧은 탐구 테스트를 진행합니다. 자동화된 테스트를 통해 버그를 찾는 것이 아니라 고객의 관점에서 변경 사항을 확인합니다. 속성에서 상태를 'validated'로 설정할 수 있습니다.

CI(지속적 통합) 시스템을 설정하여 특정 속성 세트가 있는 모든 브랜치를 모니터링합니다. 브랜치는 지정된 상태(이 경우 '검증됨')에 도달했을 때만 CI 시스템에서 고려됩니다.

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

테스트 모음이 병합을 통과하면 확인되고 CI 시스템에 제출되어 빌드하고 테스트합니다. 이 프로세스는 빌드 손상을 방지하는 데 도움이 됩니다. 실패한 경우 프로세스가 다시 시작되며, 충돌을 해결하려면 메인에서 다시 베이스해야 합니다.

테스트가 통과되면 병합이 체크인되고 브랜치가 제공될 준비가 되었습니다. 이제 상태가 'merged'로 설정되어 있습니다.

새로운 릴리스가 배포할 준비가 되면 메인 체인지 세트의 새로운 체인지 세트에 레이블이 지정되어 소프트웨어가 정식 제작에 배포됩니다.

새 작업이 이 사이클을 통과할 때마다 새로운 릴리스를 받거나 일부를 그룹화할 수도 있습니다. 연속 배포를 실습할 때 가장 논리적인 워크플로는 모든 작업을 제작에 배포하는 것입니다.

Unity Version Control을 사용하면 Jenkins, Bamboo 또는 Unity Cloud Build와 같은 선택한 CI 툴의 플러그인을 사용하여 자동화된 테스트 및 병합 단계를 구성할 수 있습니다.

이 단계는 Unity Version Control 병합 기능을 사용하여 조정할 수도 있습니다. 병합봇을 사용하면 브랜치를 병합하여 빌드가 작동하도록 트리거할 수 있습니다. 병합은 빌드가 좋은 경우에만 확인되므로 빌드 손상이 발생하지 않습니다.

유니티는 접두사 + 작업 번호라는 명명 규칙을 따릅니다. 예를 들어 브랜치의 이름은 task1213, task1209, task1221일 수 있습니다. 접두사는 'task'이며, 숫자는 관련 이슈 트래커의 실제 작업 번호를 나타냅니다.

또한 브랜치 탐색기가 이슈 트래커에서 숫자를 검색하므로 스크린샷에 각 브랜치에 대한 설명과 숫자가 표시됩니다. ‘Display branch task info’를 선택하여 브랜치 설명을 확인할 수도 있습니다.

스크럼 규칙에 따르면 작업이 16시간 이상 걸리지 않아야 합니다. 이렇게 하면 프로젝트 타임라인을 관리할 수 있습니다.

작업 브랜치를 빠르게 닫아야 합니다. 몇 시간 만에 완료할 수 있는 작은 작업이 많을 때가 이상적입니다. 이 구조는 프로젝트 리듬을 유지하고 지속적인 배포를 지원합니다. 예를 들어 일주일 동안 더 큰 작업은 주기를 멈추게 만듭니다.

기억해야 할 빨간색 플래그는 다음과 같습니다. ‘마케테 컷’ 작업을 생성하지 마세요. 작업을 작은 조각으로 잘라야 하는 경우, 별도로 작업이 유의미한지 확인하고 독립적으로 배포할 수 있어야 합니다.

작업 브랜치 워크플로는 팀 전체가 동의하면 성공할 수 있습니다.

모든 DevOps 프로세스와 마찬가지로 이 워크플로에는 문화적 요소가 있습니다. 작업 브랜치는 진행 상황을 개방적으로 전달하고 사일로를 피하는 것입니다. 워크플로나 특정 작업 방식에 대한 권한을 부여하기 전에 일관성을 높여야 합니다. 팀원들이 대규모 작업에 더 오래 걸리는 어려움이 아닌 작은 작업을 완료할 때의 이점을 이해하도록 지원하세요.

본인 또는 팀원에게 다음과 같은 질문을 하세요. 작업1209을 시작하려면 작업1213에서 완료한 코드가 정말 필요하신가요?

작업은 생각보다 훨씬 더 독립적인 경향이 있습니다. 예, 동일한 주제에 대해 다룰 수 있지만, 동일한 코드를 다룰 필요는 없습니다. 새로운 기능을 추가하기만 하면 병합에 신뢰할 수 있습니다.

위 예시에서 1213과 1209이 작업 대신 버그 수정이라고 가정해 보겠습니다. 서로에 의존하지 않기를 바라며, 메인에 도달하고 최대한 빨리 릴리스하길 원합니다. 동일한 코드를 터치하더라도 수정 사항이 다릅니다.

각 체크인은 검토자가 작업을 어떻게 처리했는지 파악하기 위해 생각과 프로세스를 따라가도록 지원해야 합니다.

전체 브랜치를 비교할 필요가 없으므로 체크인 코멘트에 세부 정보를 남겨 두면 리뷰어에게 도움이 됩니다. 대신 체인지 세트별 체인지 세트를 차별화합니다. 또한 사전 녹화된 설명을 따라 작업의 각 단계를 명확히 설명합니다. 수정된 파일이 100개 이상인 대규모 목록을 살펴보지는 못합니다. 대신 단계별로 진행합니다.

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

자동화의 이점에 부담이 적습니다. 팀은 '완성'이라는 정의에 부합해야 합니다. 즉 '정식으로 제작에 사용 가능'입니다. 반대로 작업을 제작 단계로 전환하는 과정은 쉽고 완전히 자동화되어 있으며, 오전 2시부터 화재로 인한 실습은 리드 않습니다.

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

기능 토글 버튼 / 토글 스위치 사용하면 런타임 중에 기능을 숨기거나, 활성화하거나, 비활성화할 수 있습니다. 이를 통해 개발 팀, 소수의 얼리 어답터, 또는 모두를 위한 기능만 활성화할 수 있습니다. 예를 들어 개발자 개발 중에 테스트를 위한 기능을 활성화하고 다른 사용자에게 비활성화할 수 있습니다.

예시를 살펴보겠습니다. 대규모 기능은 일곱 부분으로 나누어 작업으로 전환되고 작업 브랜치를 사용하여 구현됩니다. 다른 것이 없다면 파트 4를 어떻게 배포할 수 있나요?

파트 4는 메인 브랜치에 병합하여 기능 토글 버튼 / 토글 스위치 사용하여 숨기는 상태에서 배포할 수도 있습니다.

Hidden은 새로운 코드가 출시 전에 테스트를 건너뛰는 것을 의미하지는 않습니다. 전체 기능을 활성화할 준비가 되면 개별 부품이 이미 여러 번 테스트되었습니다. 마지막 조각을 통합하면 큰 폭의 병합이 발생하지 않으며, 작은 부분만 메인으로 통과합니다.