Git 태그에서 라이브 서버까지: 우리의 릴리스 파이프라인

요즘 Blocks Beyond The Stars의 릴리스는 명령어 하나로 이뤄져요. git 태그를 푸시하는 거예요. 그 뒤의 모든 일은 기계가 해요. 이 글에서는 우리의 CI/CD 파이프라인과, 취미 프로젝트에서도 그 수고가 왜 값진지 보여 드릴게요.

릴리스 워크플로. v0.7.4 같은 태그를 푸시하자마자 GitHub Actions가 완전한 패키지를 빌드해요. Windows 설치 파일(셋업, 포터블, MSI), 리눅스 빌드, 브라우저용 WebGL 빌드, 서버용 Docker 이미지까지, 태그 하나로 결과물 여섯 개가 나와요. 버전 번호는 태그 자체에서 가져와요. 기준이 되는 출처는 하나뿐이에요.

배포 워크플로. 두 번째 워크플로가 새 버전을 서버에 올려요. 우리에게 중요했던 건 프로덕션 게이트예요. 명시적으로 승인해야만 배포가 시작돼요. “아차, 그게 프로덕션이었네” 같은 사고는 없어요. 서버는 게임 버전을 설정 파일에 고정해 두고, 새로 깨어나는 월드는 자동으로 새 버전으로 시작해요. 이미 실행 중인 월드는 끊김 없이 그대로 두고요.

우리가 겪고서야 배운 교훈: 게임 클라이언트의 수정 사항은 진짜 릴리스가 있어야 플레이어에게 닿아요. 우리 클라이언트는 Velopack으로 스스로 업데이트하는데, 게임을 설치한 사람은 우리가 새 버전을 공개해야만 업데이트를 받아요. 메인 브랜치에 머지된 버그 수정은 태그가 뒤따르지 않는 한 아무에게도 도움이 안 돼요. 당연하게 들리지만 “고친” 버그가 왜 아직 있는지 의아했던 적이 한두 번이 아니에요.

그럼 브라우저는요? WebGL 빌드는 ZIP으로 서버에 올려서 디렉터리를 맞바꾸는 방식으로 활성화해요. 이전 디렉터리는 대비책으로 남겨 두고요. 작은 version.txt 파일이 지금 라이브인 버전을 알려 줘요.

이 모든 장치를 만드는 데 주말 몇 번이 들었어요. 그리고 릴리스할 때마다 그 값을 톡톡히 해요.