GitHub Actions 활용하기

크로키닷컴(카카오스타일)이 Jenkins → CodeBuild 를 거쳐 GitHub Actions 로 옮기며 실제로 쓰고 있는 워크플로 파일 네 벌을 공개한 글이다. 테스트 자동화, 문서 빌드·업로드, 웹 클라이언트 배포, 출시 후보(RC) 브랜치·PR 자동 생성을 각각 다룬다.

핵심 포인트

자동화가 잘 안 굴러간 이유를 먼저 밝힌다. 마이크로서비스로 잘게 쪼갠 서비스들을 단일 저장소(monorepo)로 관리하던 구조가 걸림돌이었다.
사람이 늘며 저장소를 분리하기 시작했고, 그 시점에 작성이 쉽고 확장성이 좋은 GitHub Actions 를 택했다.
테스트 워크플로는 PR 생성과 master 머지 시 돌며, MySQL 데몬을 띄우고 node_modules 를 캐시해 시간을 줄인다.
문서는 Docusaurus 로 코드와 같은 저장소에서 쓰고, PR 이면 별도 경로로 올려 커밋 상태에 링크를 달아 바로 열어 볼 수 있게 한다.
RC 준비는 목요일 새벽 4시 스케줄로 RC 브랜치를 만들고 `github-script` 로 rc→main PR 을 자동 생성한 뒤 슬랙에 알린다.

상세 정리

이력: 유닛 테스트는 초기부터 있었지만 PR·머지마다 자동 수행되지 못했고, 2017년 중반 Jenkins 로 자동 테스트만 붙였으나 워크플로와 어우러지지 못했다.
2019년 CodeBuild 로 전환하며 비로소 PR 에서 테스트 실패 시 머지를 막을 수 있게 됐지만, 매 테스트가 수십 분씩 걸리고 수정도 어려웠다.
테스트 자동화 워크플로: 트리거는 PR 생성과 master 푸시이며, MySQL 은 데몬으로 띄우되 service container 로도 가능하다고 병기한다. Node 14.x 를 쓴다.
실패 시 슬랙 알림을 보내며, 이를 위해 저장소 또는 조직 Secrets 에 슬랙 Webhook URL 을 등록해야 한다.
문서 워크플로: PR 인 경우와 주 브랜치 푸시인 경우를 `if` 로 나눠 별도 step 으로 구현했다. 하나의 step 으로 합칠 수 있을 것 같지만 빠르게 구현하느라 나눴다고 솔직히 적는다.
Docusaurus 가 문서를 절대 경로로 생성하므로 빌드 시 경로를 알려줘야 하고, 업로드용 AWS Access Key/Secret Key 는 Secrets 에 둔다.
업로드 후 생성된 주소를 커밋 상태(commit status)에 설정해, PR 화면에서 바로 문서를 열어 볼 수 있게 한 점이 실용적이다.
웹 클라이언트 배포: 백오피스 사이트는 S3 에 올려 운영하며, 이 워크플로는 자동이 아니라 GitHub Actions 화면에서 수동 실행한다.
배포 결과는 성공·실패 각각 슬랙으로 알리며 메시지에 `GITHUB_REF` 와 `GITHUB_SHA` 를 넣어 어떤 커밋이 나갔는지 남긴다.
RC 워크플로 전제: 기본 브랜치 기준으로 실행되므로 개발 브랜치가 기본 브랜치여야 한다.
RC PR 제목은 스크립트로 계산한다. UTC 기준 수요일 저녁을 기준 날짜로 삼아 그 달의 몇 주차인지 구해 "YYYY년 M월 N주" 형태로 만든다.
변경 내용이 없으면 PR 을 만들지 않고 그 사실을 슬랙에 알리도록 분기해 둔다.