📉 Github Actions CI 프로세스 개선

thumb_hyeok·2022년 10월 31일

DX ci github actions woowacourse 우아한테크코스

🔥 WoowaCourse

목록 보기

9/10

🤔 문제가 뭐야?

저번에 레벨로그의 타입스크립트 -컴파일 전략- 에서 dev와 prod의 빌드 속도를 개선하는 결과를 얻었다. Github Actions CI prod build 기준으로 약 "32초"에서 "14초" 정도로 개선을 했었다.

하지만 이건 레벨로그의 CI build 타임을 보면 아주 작은 부분이었기 때문에 다른 부분들의 개선이 필요하다고 생각했다. 아래 사진을 보자

개선 후에도, CI build 타임을 보면 약 "150s"임을 알 수 있다. 어떤 문제점들이 있는지는 하나 하나 아래에서 불릿으로 살펴보자.

백엔드, 프론트엔드 구분 없이 workflow 가 모두 트리거되어 실행된다.
프론트엔드 관련 파일만 수정된 프론트엔드 PR에서 백엔드의 테스트와 소나큐브 빌드가 실행되고 그 반대의 경우에도 프론트엔드의 빌드가 진행되었다. (여기서 생기는 부수적인 문제들도 꽤 있었다.)
모든 PR에 Dev Build 와 Prod Build 를 실행한다.
개발서버에 배포될 develop 브랜치와 운영서버에 배포될 main 브랜치에 PR에 각각의 build만 실행되지 않고, 무조건 두 가지 빌드를 다 했다.
의존성을 다운로드하는 시간이 매우 길다
전체 "150s" 가량에서 "100s" 정도를 의존성을 다운로드하는데 사용한다.
CI 과정에서 빌드만 한다
프론트엔드 CI 과정에서 "빌드"만 하고, 이미 프론트엔드에서 작성한 "테스트"들이 전혀 포함이 되어있지 않았다.
적절하지 않은 Required Status Checks
지금까지 브랜치 보호 규칙 중 Required Status Checks 에는 "build", "test" 만 포함되어있었다. 지금까지 백엔드는 소나큐브 빌드가 실패해도 merge가 막혀있지 않아서 하려고 하면 할 수 있었다.

아래에서 차례로 이런 문제들을 해결해보자!

🚀 프론트엔드 CI 개선하기

일단 프론트엔드 CI에 있는 문제들부터 해결해보기로 했다.

Dev Build, Prod Build

기존에는 프론트의 모든 workflow 가 frontBuild.yml 파일 하나에서 관리되고 있었다. 어떤 브랜치에 PR을 날렸냐에 따라 다른 workflow 를 트리거하도록 하기 위해서 front-dev.yml , front-prod.yml 로 나눴다.

"Github Actions"의 동작이 각각의 브랜치에 PR을 보냈을 때 이뤄지도록 yml 파일도 수정해주었다. 테스트 결과, 원하는 동작이 수행되는 것을 확인할 수 있었다.

의존성 캐시

다음은 시간이 가장 오래걸리는 의존성 다운로드 시간을 줄이기 위해 의존성을 캐시하고, yarn install 의 설정을 CI 환경에 맞게 바꿔주는 작업을 진행했다.

yarn install
yarn install --frozen-lockfile

yarn install 의 기본 동작은 yarn.lock 이 있고 모든 종속성을 충족하기에 충분한 경우에 package.json 에 기록된 정확한 버전의 yarn.lock 이 설치되고, 변경되지 않는다.
그러나, yarn.lock 이 없거나, 모든 종속성을 충족하기에 충분하지 않은 경우, yarn은 package.json 의 제약 조건을 충족하는 사용 가능한 최신 버전을 찾고, 결과를 yarn.lock 파일에 기록한다.

yarn install --frozen-lockfile 은 두번째 상황과 같을 경우 yarn.lock 파일을 수정하지 않고, 업데이트가 필요할 경우 실패한다. 관련된 이슈에도 나와있지만 다른 패키지 매니저 “npm”의 npm ci 와 같은 역할을 한다.

실제로 적용해본 결과 jenkins 및 알 수 없는 에러로 frosen lockfile 설정은 당장은 사용하기 힘든 것 같다! 일단 다시 되돌리고 문제를 찾아볼 예정이다.

테스트 결과, 캐시된 의존성을 사용해 Install Dependenies 과정을 생략해서 빌드 타임이 "29s" 까지 줄어든 것을 확인할 수 있었다!

테스트 자동화

마지막으로, jest 로 작성한 유닛테스트를 CI 과정에 추가했다.
아래와 같이 front-unit-test.yml 파일을 생성해 모든 브랜치에서 PR이 발생하면 트리거되어 유닛테스트 결과가 성공해야만 merge할 수 있도록 했다!

🏘️ 백엔드, 프론트엔드 CI 분리

프론트엔드 workflow 가 완료되는 시간이 "30s" 가량으로 많이 줄었지만, 무조건 백엔드 workflow 가 같이 실행되기 때문에 일찍 끝나봤자 아무런 의미가 없었다. 그리고 애초에 프론트엔드 PR에서 백엔드 workflow 까지 실행할 이유가 없다.

레벨로그의 리포지토리에는 최상단에 frontend , backend 폴더가 있다.
어떤 폴더가 수정됐냐에 따라서 각자의 workflow 만 실행하도록 수정했다.

🔒 브랜치 보호 규칙 수정

백엔드, 프론트엔드의 CI를 분리하니까 생긴 문제는 레벨로그 리포지토리의 브랜치 보호 규칙이었다. 레벨로그의 Required Status Checks 에는 build, test 가 있었다

하지만 백엔드 workflow 에는 sonarqube-build 와 test 라는 jobs만 있었기 때문에 있지도 않은 build 라는 job을 기다리느라 merge를 할 수 없는 문제가 발생했다. 이에 대한 해결책은 "Github Docs"에서 찾을 수 있었다.

해답은 동일한 이름의 job을 추가하고, 무조건 성공하도록 하는 것이다.
사실 뭔가 조금 찝찝하지만, 아직 다른 방법을 찾지는 못했다.

백엔드는 sonarqube-build 도 성공해야하기 때문에, Required Status Checks 에 추가해주었다. 프론트 workflow 에도 sonarqube-build 라는 job이 없기 때문에 위와 같은 작업을 동일하게 해줬다.