릴리스 기반 워크플로란 무엇일까요?
여기서는 GitHub를 사용하여 릴리스 기반 워크플로를 만드는 방법을 설명합니다.
릴리스 기반 워크플로란 무엇일까요?
릴리스 기반 워크플로는 소프트웨어 릴리스에 집중하는 패턴 및 정책 집합입니다. 이러한 개념이 개발팀에게는 당연한 목표로 보일 수 있지만, 이 관점의 가치는 좀 더 미묘합니다. 이번 단원에서는 프로젝트 관리, 분기 전략 선택, 고객에게 릴리스하기라는 릴리스 주기의 세 가지 요소를 진행하는 방법을 설명합니다.
GitHub 프로젝트 보드 작업 계획
계획 수립 관점에서 볼 때 릴리스 중심적이 된다는 것은 문제를 개별 반복으로 나눠 새 버전을 생성한다는 뜻입니다. 이러한 반복은 흔히 스프린트라고 하며, 각 반복은 거의 동일한 기간 동안 새 변경 내용을 생성합니다. 다른 팀들은 전체 릴리스 버전을 몇 개월 또는 그 이상 지속되는 단일 반복으로 패키징하는 방법을 선호합니다. GitHub에서는 이러한 반복을 프로젝트로 간주하여 관리합니다.
프로젝트의 핵심 기능은 보드입니다. 보드는 반복 기록을 중앙에서 기록하는 기능으로 해결해야 할 모든 카드를 포함합니다. 카드는 문제, 끌어오기 요청이나 일반 메모를 나타낼 수도 있습니다.
기본적으로 각 카드는 할 일 열에서 시작하여 작업이 시작되면 진행 중으로 이동한 다음 완료에서 끝납니다. 팀의 프로세스에 맞게 이러한 열을 사용자 지정하거나, 열을 추가하거나, 이러한 카드와 해당 속성의 이동을 자동화할 수 있습니다.
프로젝트 보드 관리에 대해 자세히 알아보세요.
카드의 프로젝트 상태는 리포지토리 전체에서 통합됩니다. 예를 들어 카드를 할 일에서 진행 중으로 끌어오면 상태가 변경되고 프로젝트 제목 옆에 있는 시각적 표시기가 업데이트됩니다. 녹색 부분은 완료로 표시된 카드 부분이며 자주색은 진행 중인 카드를 의미합니다. 남은 부분은 아직 시작하지 않은 카드 수량을 의미합니다. 카드를 보드 주위에서 끄는 작업에 더해 기본 보기에서 카드를 업데이트할 수도 있습니다.
프로젝트 보드를 사용하면 모든 관련자가 프로젝트의 상태와 개발속도를 쉽게 이해할 수 있습니다. 개별 사용자 또는 조직에서 소유한 리포지토리의 컬렉션으로 범위를 지정한 보드를 만들 수도 있습니다.
프로젝트 보드를 사용하여 작업 진행 상황 추적에 대해 자세히 알아보세요.
특정 마일스톤 추적
GitHub는 팀 또는 팀의 하위 집합에게 마일스톤 추적을 제공합니다.
마일스톤은 문제 및 끌어오기 요청 완료에 우선 순위를 두는 프로젝트 추적이라 할 수 있습니다. 하지만 프로젝트가 팀의 프로세스에 초점을 맞춘다면 마일스톤은 제품에 초점을 맞춥니다.
마일스톤 사용하여 작업 진행 상황 추적에 대해 자세히 알아보세요.
분기 전략 선택
여러 개발자가 동시에 작업하는 리포지토리에는 명확하게 정의된 분기 전략이 필요합니다. 프로젝트 초기부터 통합된 방식을 정하면 팀과 코드베이스가 크기 조정될 때 혼동과 좌절을 줄일 수 있습니다.
GitHub 흐름
GitHub는 공동 소프트웨어 개발용 플랫폼을 제공할 뿐만 아니라 다양한 자체 기능을 최적화하도록 설계된 정해진 워크플로도 제공합니다. GitHub는 사실상 모든 소프트웨어 개발 프로세스와 호환되지만, 팀에서 아직 프로세스를 정하지 못했다면 GitHub 흐름을 고려해 보는 것이 좋습니다.
장기 분기 관련 작업
장기 분기는 삭제되지 않는 Git 분기입니다. 일부 팀은 장기 분기 대신 단기 기능 및 버그 수정 분기를 선호합니다. 이러한 팀의 목표는 작업을 다시 main로 병합하는 끌어오기 요청을 생성하는 것입니다. 이 방법은 이전 버전을 지원하지 않는 자사 웹 애플리케이션처럼 조회할 필요가 없는 프로젝트에 효과적입니다.
하지만 장기 분기가 팀에게 가장 도움이 되는 상황도 존재합니다. 장기 분기를 사용하는 가장 일반적인 경우는 오랫동안 지원되어야 하는 여러 버전이 제품에 존재하는 경우입니다. 팀이 이러한 작업을 하기로 했다면 리포지토리는 release-v1.0, release-v2.0 같은 표준 규칙을 따라야 합니다. 또한 이러한 분기는 GitHub에서 보호 항목으로 표시되므로 쓰기 권한이 제어되며 실수로 삭제할 수 없습니다.
하지만 팀은 main를 루트 분기로 유지하고 관련 릴리스 분기 변경 사항 업스트림이 프로젝트의 미래에 어울린다면 병합해야 합니다. 때가 되면 main를 바탕으로 release-v3.0을 만들어 release-v2.0용 서비스 작업 때문에 리포지토리가 복잡해지지 않게 해야 합니다.
장기 분기 서비스
버그 픽스를 release-v2.0 분기에 통합한 다음 업스트림을 main로 다시 병합했다고 가정해 보세요. 그런 다음 나중에 이 버그가 release-v1.0 분기에도 존재하고 해당 버전을 계속 사용하는 고객을 위해 수정 사항을 백포트해야 한다는 것을 알게 되었습니다. 이 수정 사항을 백포트하는 가장 좋은 방법은 무엇인가요?
main 분기를 release-v1.0으로 병합하는 것은 해당 버전에 포함되지 않도록 의도된 커밋이 상당수 포함되기 때문에 실행 가능한 옵션이 아닙니다. 같은 이유로 release-v1.0을 현재 main 커밋으로 기준 주소를 다시 지정하는 것은 옵션이 아닙니다.
대안적인 방법은 release-v1.0 분기에서 픽스를 직접 다시 구현하는 것이지만, 이 방법은 다량의 재작업을 요구하며 여러 버전으로 확장하기가 어렵습니다. 하지만 Git는 이 문제에 대한 자동화된 솔루션으로 cherry-pick 명령을 제공합니다.
Git의 cherry-pick 명령이란 무엇일까요?
git cherry-pick은 특정 커밋을 한 분기에서 다른 분기에 적용할 수 있도록 하는 명령입니다. 이 명령을 선택한 커밋을 반복하고 대상 분기에 새 커밋으로 적용합니다. 개발자는 필요하다면 백포트를 완료하기 전에 모든 충돌을 병합할 수 있습니다.
Git의 cherry-pick에 대해 자세히 알아보세요.
소비자에게 릴리스
제품 버전을 릴리스할 준비가 되면 GitHub는 이를 패키징하고 고객에게 알리는 프로세스를 간소화합니다.
버전 생성은 양식을 작성하는 것만큼 간단합니다.
- 적용할 Git 태그를 입력하세요. 유의적 버전를 준수해야 합니다(예:
v1.0.2). GitHub는 사용자가 지정하는 Git 태그 생성 프로세스를 관리합니다. - 릴리스의 이름을 입력하세요. 일반적인 방법은 다음과 같습니다.
- 릴리스를 설명하는 이름을 사용합니다.
- Git 버전을 사용합니다.
- 이전 릴리스 이후 릴리스가 어떻게 변경되었는지 간결하게 요약합니다.
- 코드 이름 또는 임의의 문구를 사용합니다.
- 릴리스 정보를 입력합니다. 이 작업은 이전 버전 이후 변경 내용을 분석하고 관련된 끌어오기 요청 제목을 포함하는 Release Drafter 앱으로 자동화할 수 있습니다.
- 파일을 미리 빌드한 설치 관리자 같은 릴리스 구성 요소로 제공하고 싶다면 양식까지 끌어다 놓으면 됩니다. GitHub에서 자동으로 처리하므로 원본을 패키징하지 않아도 됩니다.
- 해당 상자를 선택하여 해당 버전이 시험판인지 여부를 나타냅니다. 이 표시는 시험판 버전을 원하지 않는 고객에게 도움이 됩니다.
릴리스가 게시되면 리포지토리를 감시하는 모든 사람이 알림을 받습니다.
GitHub 릴리스에 대해 자세히 알아보세요.