Github Actionsworkflow 작성로컬 환경 workflow 실행이슈 사항의존성 패키지 캐싱이슈효과서버 환경에 따른 CI/CD 구분job 중복called workflow 특징기타 이슈 사항build 과정 에러고민중복되는 stepE2E 테스트 실행 순서Vercel 환경에 Github Actions 적용후기
해당 포스트는 주관적인 내용이 많이 담겨 있습니다.
별도의 사용법은 다루지 않습니다.
지금까지 작성한 테스트 코드를 CI 과정에 추가하기 위해서 Github Actions 의 workflow 를 작성하여 CI/CD 파이프라인을 구축하였다.
Github Actions
GitHub Actions 는 빌드, 테스트 및 배포 파이프라인을 자동화할 수 있는 CI/CD(연속 통합 및 지속적인 업데이트) 플랫폼입니다. - github actions 공식 문서
Github Actions 를 통해 레포지토리에서 특정 브랜치에 이벤트(push, pr 등) 가 발생하면 특정 작업(workflow) 을 자동으로 실행할 수 있다.
workflow 작성
해당 프로젝트에서는 workflow 의 jobs 를 test, e2e 로 분리하여 workflow 를 작성하였다.
로컬 환경 workflow 실행
아무래도 workflow 를 처음 작성하다 보니 작성한 workflow 를 로컬 환경에서 테스트 실행하고 싶었다.
그래서 방법을 찾다가 act 를 찾게 되었고 act 설치 후 로컬 환경에서 테스트 실행을 할 수 있었다.
이슈 사항
act 를 통해 로컬 환경에서 실행이 되긴 했지만 내 컴퓨터 사양이 좋지 않아서 그런지 실행 시간이 오래 걸렸다. (Github Actions 를 통해 실행했을 때 실행 시간이 70% 이상 감소한 것을 보면 act 또는 컴퓨터 사양 이슈인 것 같다.)
의존성 패키지 캐싱
test 와 e2e job 에는 의존성 패키지를 설치하는 과정이 포함되어 있다.
이 부분에서 동일한 의존성 패키지를 중복으로 설치한다는 부분에서 찜찜함을 느껴 해결 방법을 찾게 되었고, 이를 캐싱을 통해 해결할 수 있다는 것을 알게 되어 적용하게 되었다.
이슈
캐싱이 되어 있는 상황에서 의존성 패키지 추가 후 workflow 실행을 하니 에러가 발생하였다.
workflow 동작 시 기존 A 라는 캐싱 데이터를 사용하는데 A 라는 캐싱 데이터에는 추가된 의존성 패키지가 포함되어 있지 않아서 발생하는 문제이다.
이 문제를 캐시의 key 값에
hashFiles(yarn.lock) 를 적용하여 해결할 수 있다. 의존성 패키지가 추가되면 yarn.lock 파일이 업데이트되는데 이 점을 활용해 yarn.lock 파일의 해시 값을 캐시의 key 값으로 적용하여 캐시의 존재 여부를 파악할 수 있다.설치 과정에서 이미 해당 의존성 패키지와 동일한 key 를 가진 캐시가 존재한다면 의존성 패키지가 변경되지 않았기 때문에 기존 캐시를 사용하고, 존재하지 않는다면 의존성 패키지가 변경되었기 때문에 캐시를 최신 버전으로 업데이트 하는 과정을 적용할 수 있다.
효과
의존성 설치가 현재 프로젝트 기준 30초 정도가 소요되는데, 캐싱을 통해 이 작업을 생략할 수 있게 되어 약 1분 정도의 시간을 단축할 수 있었다. (test 30초 + e2e 30초)
서버 환경에 따른 CI/CD 구분
해당 프로젝트의 경우 서버 환경에 따라 CI/CD 파이프라인 과정에 차이가 있다.
- 개발: test → deploy → e2e(개발)
- 운영: test → deploy
job 중복
이때 test, deploy job 이 중복되는데 이 중복되는 job 을 재사용할 수 있는 방법을 찾아보기로 하였고 workflow 내부에
workflow_call 을 설정하여 workflow 를 불러올 수 있게 하는 방법을 찾을 수 있었다.여기서 재사용할 수 있는 workflow 를 called workflow 라고 하고, 이 workflow 를 불러오는 workflow 를 caller workflow 라고 한다.
해당 환경에서 called workflow 는 test, deploy 이고 caller workflow 는 ci-cd 이다.
called workflow 특징
on.workflow_call를 명시해야한다.
- caller workflow 에서
<job>.with를 통해 전달한 값을workflow_call.inputs으로 받을 수 있다.
- 자체적으로 환경 변수(
secrets.<KEY>) 를 사용할 수 없다. 이런 경우 caller workflow 에서job.secrets를 통해 값을 전달하고 이를workflow_call.secrets으로 받을 수 있다. - 일일이 called, caller workflow 에 설정하는 방법도 있지만
inherit키워드를 사용하여 caller workflow 에서 환경 변수를 상속시켜 줄 수 있다.
기타 이슈 사항
build 과정 에러
workflow 작성 후 실행을 하는데 프로젝트의 build 과정에서 에러가 발생하였다.
어찌 보면 당연한 이유인데 해당 프로젝트에서 .env 파일을 통해 환경 변수를 사용하고 있는데 workflow 환경에는 .env 파일이 없기도 하고 사용도 하지 않기 때문에 에러가 발생하는 것이다.
그래서 프로젝트 레포지토리의 secrets 설정(/settings/secrets/actions) 페이지를 통해 환경 변수를 추가하여 workflow 환경에 환경 변수를 적용하였다.
고민
중복되는 step
각각의 jobs 영역에는 node 설치와 의존성 패키지 설치 등의 과정이 존재하는데 이 과정들이 job 마다 중복으로 설정이 되어있는 것을 확인하였고 중복을 제거할 수 있을지에 대한 고민을 했었다.
이 부분에 대해서 YAML 의 anchor 를 알게 되었지만 Github Actions 이슈를 보니 아직은 Github Actions 에서 지원하지 않는 것 같았고,
workflow_call 를 적용한 called workflow 로 job 을 재사용하여 중복을 제거할 수 있지만 해당 프로젝트는 중복되는 단계의 다음 단계에 각각의 job 에 해당하는 추가 step 이 존재하기 때문에 활용하지 못했다.E2E 테스트 실행 순서
workflow 를 모두 작성하고 동작 테스트까지 완료된 상태에서 E2E 테스트의 실행 순서에 대한 고민을 했다.
- 테스트 → 로컬 환경 빌드 → E2E 테스트 실행 → 서버 배포
- 테스트 → 서버 배포 → E2E 테스트 실행
1번 과정은 로컬 환경과 실제 배포 환경이 다르다 보니 E2E 테스트의 목적과 다르다고 생각했고, 2번 과정은 배포를 먼저 하다 보니 사전에 에러를 발견하지 못해 사용자에게 좋지 않은 경험을 줄 수도 있을 거란 생각을 했다.
이 고민에 대해서는 현재 개발하고 있는 상황에 따라 달라진다고 생각했다.
만약 개발 하는 환경이 staging 서버 등의 테스트 서버가 존재하지 않고 production 서버만 존재하는 환경이라면 1번 과정을 적용하는 게 좋고 존재한다면 2번 과정을 적용하는 게 좋다고 생각했다.
그런데 1번 과정을 적용하는 경우, 로컬 환경에서는 동작하지 않고 https 환경에서만 동작하는 기능을 테스트할 때에 대한 대책이 필요해 보였다.
Vercel 환경에 Github Actions 적용
블로그는 현재 Vercel 에 Github 레포지토리를 연결해서 배포를 진행하고 있다.
이 상황에서 Github Actions 을 적용하여 테스트 후 배포를 진행하도록 설정하였다.
적용 과정을 별도의 포스트를 통해 정리하였다.
후기
어느 정도 개념만 알고 있었던 Github Actions 를 실제 운영하는 프로젝트에 적용해 보니 재밌기도 했고 내가 작성한 테스트를 검증 단계에 적용한 뒤에 배포를 진행하니 왠지 모를 안정감이 느껴져서 뿌듯하기도 했다.
추후에 Vercel 뿐만 아니라 AWS 나 기타 환경에서도 Github Actions 를 활용해 자동화 작업을 해보고 싶다는 생각이 들었다.
참고
