핏펫 커머스 스쿼드가 배포 태그와 릴리즈 노트를 손으로 만들던 것을 GitHub Actions 스크립트로 자동화한 기록이다. 프론트는 날짜 기반, 백엔드는 수동 Semantic Version 이라 일관성이 없었고, 슬랙 공지를 위해 PR 마다 적힌 아사나 링크를 사람이 모아 재구성하던 것을 함께 없앴다.
핵심 포인트- 목표 세 가지는 일관성(사용 기술 무관), 자동화(수동 태깅 제거), 공유 용이성(바로 슬랙에 올릴 수 있는 릴리즈 노트)이다.
- 프론트는 `YYYY-MM-DD-hhmm` 태그를 써서 유니크하지만 사실상 난수라 이전·다음 버전을 짐작할 수 없었다.
- 백엔드는 Semantic Version 을 손으로 붙이다 보니 버전을 건너뛰는 실수가 났고, 매번 이전 태그를 확인해야 했다.
- 이미 GitHub Actions 로 배포하고 있었으므로 `actions/github-script` 로 JavaScript 를 실행해 태그 생성과 노트 작성을 함께 처리했다.
- 스크립트는 별도 저장소로 분리해 여러 repo 가 공통으로, 항상 최신 버전을 쓰게 했다.
상세 정리- 문제의 실체: 바쁜 날 배포 때마다 반복되는 클릭과 입력이 스트레스였고, 유관 부서는 PR 링크로 내용을 볼 수 없어 아사나 링크를 따로 모아 공지를 다시 구성해야 했다.
- 언어 선택: 빠르게 하려면 JavaScript 로 충분하지만 실수를 줄이려고 webpack + TypeScript 로 개발했다. GitHub API 타입을 쓰려고 Octokit 을 설치했다(기능 구현에 필수는 아니었다).
- 배포 형태: 만든 패키지를 GitHub Registry 에 올려 워크플로에서 npm 으로 설치해 쓴다.
- `createRelease` 는 두 가지를 한다. `generateNewTagFromLatestRelease` 로 새 태그를 만들고, creator 함수로 GitHub 에 릴리즈 노트를 생성한다.
- 버전 증가 규칙: 워크플로 input 으로 받은 `upgradeVersionType` 에 따라 major 는 앞자리 증가 후 나머지 0, minor 는 가운데 증가 후 마지막 0, patch 는 마지막 자리만 증가시킨다. 기본값은 patch 다.
- input 전달: `github-script` 의 `context.payload` 로 워크플로에서 고른 input 을 받는다. 실행 조건은 수동 실행(`workflow_dispatch`)이다.
- 노트 내용 생성: GitHub 이 자동 생성한 노트의 URL 에서 `pull` 뒤 PR 번호를 뽑아 각 PR 의 제목·번호·아사나 URL 을 가져온다. 아사나 URL 형식이 없으면 "Asana link가 없습니다" 로 채운다.
- 결과물: 비개발 부서는 아사나 URL 로 배포 내용을, 개발자는 PR 링크로 코드를 확인할 수 있는 릴리즈 노트가 만들어져 슬랙에 그대로 공유된다.
- 워크플로 job 구성: `create-release` job 안에 npm 설치 → 현재 스크립트 버전 출력 → `github-script` 로 스크립트 실행 3단계를 둔다.
- 스크립트를 별도 repo 로 둔 이유는 여러 repo 공통 사용과, 프로젝트 안에서 고치면 프로젝트와 무관한 커밋이 쌓이는 문제를 피하기 위해서다.
- 남은 과제 ①: 버저닝 스크립트에 테스트 코드가 없어 리팩터링이 어렵다. 테스트용 repo 를 만들어 돌려보는 방식은 비효율적이라, 처음부터 테스트를 넣었어야 했다고 회고한다.
- 남은 과제 ②: git tag 로만 버전을 관리하니 소스코드만 있는 환경에서는 버전을 알 수 없다. GitHub API 로 조회하려면 항상 토큰이 필요해, 프로젝트 안에 버전을 남기는 다른 방법을 고민 중이다.
왜 읽나배포 태그와 릴리즈 노트를 아직 손으로 만들고 있는 팀에게, GitHub Actions 안에서 끝내는 구성과 그 한계를 함께 보여준다.
핏펫·
AWS Korea Tech·
GitLab Blog·