릴리스 기반 워크플로란 무엇일까요?
여기서는 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 하는 것은 해당 버전에 속하지 않은 많은 커밋을 포함하므로 실행 가능한 옵션이 아닙니다. 같은 이유로 현재 main 커밋에 대한 재지정 release-v1.0 은 옵션이 아닙니다.
대안적인 방법은 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 릴리스에 대해 자세히 알아보세요.