gitlab runner 로 ci 만들어보기

개요

• 이번에 이직한 회사에서 gitlab 을 사용하는데, cicd 가 되어있지 않아 배포 과정이 수동적이었다
• 이에 따라서 gitlab runner 구성과 gitlab ci 스크립트 작성을 통해 자동화 배포 환경을 구축하게 되었다

Gitlab runner 구성

• 먼저 gitlab runner 구성하는 작업을 진행했다
• gitlab runner 는 ci/cd 파이프라인을 실행하는 역할을 한다
• 관련 가이드를 참고해서 runner 를 성공적으로 설치 / 등록할 수 있었다
  • 초기 구성은 여기가 잘 나와있음

Gitlab ci 스크립트 작성

• 그 다음으로는 .gitlab-ci.yml 파일을 작성해서 ci/cd 파이프라인을 구성했다.
• 나는 파이프라인을 다음과 같은 단계로 나눴다

1. Compile:dev 단계
   • develop 브랜치의 mr 이벤트 발생 시 실행
   • yarn install, git pull, yarn build 실행
   • 빌드 결과물은 사용되지 않음
2. Build:dev 단계
   • develop 브랜치에 push 이벤트 발생 시 실행
   • git pull origin develop, yarn install, yarn build 수행
   • 빌드 결과물을 out 디렉토리에 artifacts 로 저장
3. Deploy:dev 단계
   • develop 브랜치에 push 이벤트 발생 시 실행
   • Build:dev 단계의 artifacts 를 의존
   • out 디렉토리의 결과물을 개발 서버에 배포

3개의 단계로 나눈 이유

1. Compile:dev 단계
   • MR 을 머지한 이후 빌드 오류가 나는 경우가 잦았다
   • 따라서 머지 이전에 빌드 오류가 나는지 확인한 뒤 머지할 수 있도록 강제성을 두기 위해서 만든 것이다
2. Build:dev 단계
   • Compile 단계에서 만든 빌드 파일을 사용하면 되지 않을까 싶겠지만,
     그렇게 하게 되면 서로의 커밋이 최종 파일을 덮어버리는 이슈가 생겼다
   • 예를 들어 a MR 이 방치되던 중 b MR 을 생성 > b MR 이 먼저 머지 및 빌드 > a MR 이 머지 및 빌드
     이런 경우에는 b 가 머지되었음에도 불구하고 a 시점의 코드가 나가게 되므로, b 내용이 전부 사라지게 된다
     따라서 Build:dev 단계에서는 머지된 develop 최신 브랜치를 땡겨오고, 그것을 빌드하게끔 했다
3. Deploy:dev 단계
   • Build 된 파일을 그대로 사용하는 단계이다
   • gitlab 서버와 배포 서버는 다르기 때문에 나눴다

TODO

• 급하게 만든 CI 라 아직 고쳐야 할 점이 있다

1. Compile:dev 에서는 캐싱된 node_modules 를 사용하고,
   package.json 이 업데이트 되지 않았다면 yarn install 을 건너뛰기
   • 현재는 매번 yarn install 을 하기 때문에 MR 생성 시 컴파일이 느린 감이 있다
2. 컴파일을 체크하기 위한 스크립트를 간소화 할 수 없는지 확인
   • next 프로젝트를 빠르게 컴파일 할 수 있는 방법이 없을지...
   • lint 는 진짜 린트 체크만 해서 실제 빌드와는 또 다르다..
3. 빌드를 병렬로 할 수는 없을지
   • ci 단계에서 안 적은 것이 있는데, 사실은 퍼블팀을 위한 빌드 단계가 또 있다
   • 기본 build/deploy 단계는 퍼블리싱 파일 미포함이지만, 퍼블팀에서 실 서버를 봐야 하는 이슈가 생겼었다
   • 따라서 포트를 두 개 띄우고 퍼블팀만 볼 수 있는 서버를 하나 더 띄워서 보게끔 만들었다
     내부 사정으로 각각 export 옵션 / standlone 옵션으로 상이하기 때문에 어쩔 수 없이 두개를 띄웠다
   • 그래서 빌드가 두개가 직렬로 돌고 있어서 퍼블 CI/CD 는 상대적으로 느린데, 빌드를 병렬로 할 수 없을지 찾아봐야 한다