📝 핏펫의 배포시 버저닝 관리 자동화하기

이번글에서는 핏펫의 커머스 스쿼드에서어떻게 웹 버저닝을 하고 있었는지
그리고 어떤 개선을 시도했고, 앞으로 할일은 무엇이 있을지 작성해보았습니다.

고민의 시작

커머스 스쿼드에서는 프론트엔드, 백엔드간의 Versioning 방식이 없었습니다. Versioning 을 위해서 Release Note에 직접 tag값을 입력하고 있었습니다.

바쁘지 않을때는 크게 문제가 없었으나 정신없이 바쁜날에는 배포를 위해서 해야하는 여러번의 클릭과 입력은 스트레스가 되기에 충분했습니다.

이런 반복적인 작업을 줄이기 위해서는 자동화된 버저닝이 필요하다고 생각되었고, 사용기술에 관계없는 버저닝방식이 있으면 더 좋을 것 같았습니다.

배포 후에는 Release Note 내용을 모든 구성원이 있는 slack 채널에 공지하였는데, 공지 내용에는 task 링크 (아사나 링크)를 함께 적어줘야했습니다.

유관부서에서는 pr 링크로 내용확인을 할수가 없었기 때문입니다. 이를 위해서는 PR에 적어둔 아사나 링크를 다 가져와서 내용을 재구성해야했는데, 이것 또한 귀찮고 시간이 아까운 일이었습니다.

이러한 이유로 버저닝을 하면서 Release Note 내용도 커스텀을 하면 좋겠다라는 생각을 하게 되었습니다.

그래서 무엇이 필요한가?

• 사용기술에 관계없는 자동화된 버전관리
• 바로 공유하기 편한 Release Note의 생성

👀 기존방식

무슨 버전이라고?

프론트엔드는 YYYY-MM-DD-hhmm 형식으로 시간을 tag로 사용하고 있었습니다.

시간형식의 tag는 유니크한 값이기 때문에 이전에 버전에 대해서 몰라도 되는 장점이 있었습니다.

❗️하지만 현재 버전 tag와 미래 버전 tag에 대한 추측이 안되는 것이 단점이었습니다. (날짜, 시간이기 때문에 사실상 난수로 느껴졌습니다.)

프론트엔드의 초기 Release Note

백엔드는 Semantic Version 형식의 tag를 사용하고 있었습니다.
tag 생성은 수동으로 하였기에, 실수로 건너뛰는 버전이 발생하기도 했습니다. 🤭
버전 순서를 잘 지키기 위해서는 이전 tag가 무엇인지 체크가 필요했습니다.

백엔드의 초기 Release Note

그렇다면… “우리의 웹은 일관성있는 버전관리가 되고 있는가?” 에 대한 고민이 되기 시작했습니다.

우리는 어디에 있는가?

🎯 목표

1. Consistency : 사용기술에 무관한 (javascript, python 등) 버저닝 방식
2. Automatic : 수동버저닝에서 자동으로 버저닝으로의 변경이 필요
3. Easy : 배포후에 유관부서 및 개발자들에게 바로 공유할 수 있는 Release Note

Github Action을 사용하여 서버 배포를 하고 있기 때문에, Github Action을 사용하여 Release Note를 생성해보기로 했습니다.

Action의 workflow(*.yml)파일에서는 shell script를 실행할 수 있습니다. 그리고 github-script를 사용하면 javascript로 실행이 가능합니다.

GitHub - actions/github-script: Write workflows scripting the GitHub API in JavaScript

typescript로 개발하기

빠른 개발을 위해서는 javascript만 사용해도 되지만, 아무래도 실수하기 쉬운 javascript만으로는 부족하다고 생각되었습니다.
그래서 typescript로 개발할 수 있도록 webpack, typescript를 설치했습니다.

💻 프로젝트 Setup

script 추가

• build 스크립트: package.json에서 기존 build file 삭제 및 webpack 실행

npm 패키지 설치

• Ocktokit은 Github API를 사용할 수 있는 패키지입니다.
  저는 Octokit의 type을 사용하기 위해서 설치하였습니다. (github-script이 Octokit을 사용하고 있기 때문에 기능구현을 위해서 필요하지는 않았습니다.)

octokit/rest.js

GitHub - actions/github-script: Write workflows scripting the GitHub API in JavaScript

package.json에 설치한 npm 라이브러리

package를 Github Registry에 배포하기 위해서 작성

어떤 순서로 만들면 될까?

전체 프로세스를 콜스택으로 표현하였습니다.

노란영역 : Github API 를 의미합니다.
파란영역: 일반 함수를 의미합니다.

Example — Functional Code

글의 가독성을 위해서 실제 코드에서 일부 코드(내용 이해에 꼭 필요하지 않은 코드, try…catch문, console, 예외처리)는 제외하고, 읽기 쉽도록 변형하였습니다.

타입정의

코드에서 사용하는 Type입니다. (기능에 영향을 주는 부분이 아니고 자동완성을 위해서 추가한 type이므로 설명은 주석으로 대신하겠습니다.)

Release Note 생성 함수

createRelease 는 2가지 일을 합니다.

1. 신규 버전 생성 : generateNewTagFromLatestRelease를 사용하여 신규 tag를 생성합니다.
2. Release Note 생성 : creator 함수는 Github에 Release Note를 생성합니다.

신규 tag 생성함수

generateNewTagFromLatestRelease : 신규 tag(버전)을 생성합니다.

신규 tag를 생성할때는 input이 필요합니다.
input 은 어떤버전으로 업그레이드를 할지 결정하게 도와줍니다.

github-script의 context.payload에는 Action의 workflow에서 선택한 input을 받을 수 있습니다.

(어떻게 workflow의 input을 받는지는 아래에 <Example — Action Code> 파트에서 설명하겠습니다.)

만약 input으로 받은 변수값이(upgradeVersionType)으로 버전형식이 결정됩니다.

• major : 가장앞의 숫자를 증가 및 나머지는 0으로 변경
• minor : 중간 숫자를 증가 및 마지막 숫자를 0으로 변경
• patch : 마지막 숫자를 증가시킴

Release Note 컨텐츠 생성함수

generateReleaseNoteContent : Release Note에 넣을 내용을 생성합니다.

getPR은 각 PR에서 필요한 정보(Title, PR Number, Asana URL)를 가져옵니다.

generateReleaseNotes에 의해 자동으로 생성한 Note

자동생성된 내용 및 URL은 이런 형태를 갖습니다.

자동생성된 내용의 형식을 참고해보면 url의 pull 뒤에있는 pr번호를 가져오고, PR의 내용을 가져올 수 있습니다.

(참고. 저희 커머스(탐색, 주문) 스쿼드에서는 PR의 내용에 Asana URL을 넣습니다.)

Asana URL이 있는 경우는 제목과 PR번호를 가져옵니다. (URL 형식이 없는 경우는 “Asana link가 없습니다.”)

✅ Release Note의 완성

마법같이 깔끔한 Release Note

이제 Release Note는 이런형식으로 생성됩니다.

이렇게 생성된 Release Note는 바로 slack 채널에 공유될 수 있습니다. 👨‍👦‍👦

정리된 Release Note 내용을 바탕으로 비개발 부서에서는 아사나 URL로 배포내용을 확인할 수 있고, 개발자는 PR 링크를 통해서 코드확인을 할 수 있습니다.

Example — Action Code

핏펫몰의 Action에서 Release Note를 만들어내는 작업을 수행하기 위해서는 javascript 를 직접 실행할 수 있는 github-script를 사용하는것이 편합니다.

workflow 실행조건 (on)

• 수동실행 — workflow_dispatch
• generateNewTagFromLatestRelease에서 사용한 inputs값을 여기에서 확인할 수 있습니다.
• 기본값은 patch 해주었습니다.

workflow의 작업 (job)

create-release라는 job을 만들었습니다. job에는 3가지 step이 있습니다.

Install NPM(npm 설치)

• 위에서 작성하고 배포한 스크립트를 설치합니다.

Print Current Version(현재 버전표시)

• 현재 사용하는 스크립트의 버전을 표시합니다. 스크립트를 별도의 repo로 관리하는 이유는 2가지가 있습니다.
• 여러 repo에서 공통으로 사용
• 항상 최신버전의 스크립트를 사용 (프로젝트 내에서 수정하면 프로젝트와 상관없는 commit을 만들고 배포해야합니다.)

Create Release(스크립트 실행)

• github-script는 기본적으로 github, context object를 제공합니다. 이것을 넘겨서 사용한것이 스크립트 코드에 GithubScriptInput 타입입니다.

실행할때는 이렇게 input에서 버전형식을 할 수 있습니다.

🚀 마무리하며

🥰 어떤것이 좋아졌나?

버저닝을 자동으로 하게 되면서 확실히 tag 생성에 대한 부담이 사라졌습니다. 직접 스크립트를 만들었기 때문에 필요하다면 원하는대로 버저닝 방법을 수정할 수 있습니다.
github action으로 실행하기 때문에, 프로젝트의 사용기술에 상관없이 git의 tag로 버저닝이 가능하게 되었습니다.

🤔 더 고민해야할 내용

<테스트코드의 부재>
현재 버저닝 스크립트에서는 테스트 코드가 없습니다.
테스트 코드가 없으므로 리팩토링을 하기가 쉽지 않습니다. 테스트용 repo를 만들어서 실행해보면 되지만 꽤나 비효율적인 방법입니다.
테스트 코드를 적용하기 위해서는 현재 함수들을 테스트 적용이 가능한 코드로 변경해야합니다. 처음부터 테스트 코드를 넣었다면 더 좋았을것 같습니다.

<프로젝트내에 버전표시 불가>
git tag로 버전관리를 하기 때문에, git이 없는 환경에서는 (프로젝트 소스코드만 있는 상황) 버전을 알 수가 없습니다.
github API로 Latest Release 를 조회하면 되지만, 이 방식은 항상 token이 필요합니다. 따라서 프로젝트내에 현재 버전을 저장할 수 있는 다른 방법에 대한 고민도 필요합니다.

읽어 주셔서 감사합니다.

Reference

• semantic version : https://semver.org/
  github-script : https://github.com/actions/github-script#actionsgithub-script
  Octokit 문서 : https://octokit.github.io/rest.js/v18

written by Steven (Sungjin Cho)

email: sj_cho@fitpet.co.kr