GitHub Actions - CI/CD 도입 - 1 (feat. Cheffi)

개요

이번 Cheffi 프로젝트를 진행하면서 꼭 해보고 싶었던 것 중 하나가 CI/CD 파이프라인 구축이었다. 저번 프로젝트(Glims)에서 배포를 내가 담당했었는데 낮에는 회사일로 바쁘고 밤에는 회사 프로젝트를 위해서 Vue.js 공부를 하다보니 CI/CD 공부를 할 수 있는 물리적인 시간이 부족했었고, 프로젝트 진행 내내 수동 테스트와 배포를 반복했었다.

 

 

 

직접 경험한 수동 배포의 문제점

1. 서버 업데이트가 늦다.

매번 수동 배포를 하다보니 팀원이 기능을 추가하거나 디버깅을 해도 수정이 반영되려면 항상 내가 배포를 해야했다. 내가 변경을 인지하고 작업할 수 있는 상황이어야만 배포가 가능해지니 기능 업데이트가 나라는 병목현상(?)을 겪게 되는 것이다. 내가 개인 사정으로 바쁠때는 나의 배포를 하염없이 기다려야만 하는 상황이 되는것이다.

 

 

2. 배포하는 커맨드가 가물가물하다 

프로젝트 초기에는 서버 코드 업데이트와 배포가 잦다보니 배포 관련 도커와 리눅스 커맨드를 잊어 버릴 일이 없었다. 하지만, 기능 업데이트가 뜸해지면서 배포하려면 어떤 커맨드를 작성해야 했었는 지 기억에 의존해야 했기 때문에 배포를 하고 나서도 종종 무언가 작업을 하지 않았다는 찜찜한 느낌이 들었다. 복잡한 커맨드를 쓴 것도 아닌데 이런 문제를 겪었으니 실무에서는 더 큰 장애요소로 다가올 것 같았다. 

 

 

3. 배포 후 프론트에게 알리는 작업

배포하고 나서도 배포가 완료되었다고 슬랙에 공지를 매번 해줘야 했었다. 왜냐면 당연하게도 프론트엔드 개발자들은 배포했다고 배포한 사람이 알려주지 않으면 알 길이 없기 때문이다. 내가 작업하지 않은 코드를 배포할 때도 내가 알려줘야 했기 때문에 부담감을 더 느꼈었던 것 같다.

 

4. 코드가 깨져 빌드가 실패해도 빠른 파악이 불가능하다.

종종 코드리뷰를 마친 PR도 다양한 사유로 Merge를 한 이후에 컴파일 에러나 테스트 실패로 빌드 자체가 안되는 경우가 많았다. 문제는 배포를 할 시점이 되어서야 컴파일 에러, 테스트 실패같은 요소를 확인할 수 있다는 점이다. 변경사항을 배포를 한 시점에 이런 문제가 발생한다면 해당 코드를 작성한 팀원은 이미 해당 코드에서 자리를 떠난 이후이기 때문에 문제의 코드를 작성한 팀원이 코드의 문제점을 인지할 때까지 기다려야 하며 코드의 맥락도 완벽하게 기억이 나지 않을 수도 있다. 비효율적인 디버깅 환경이라고 할 수 있다.

결국, 상기한 문제점들로 인해 다음 프로젝트에서는 CI/CD 파이프 라인을 구축하기로 마음을 먹었다.

 

툴 선택

원래는 Jenkins를 조금 공부했었어서 Jenkins를 사용하고 싶었으나 이번 프로젝트에서 몇 팀원들이 GitHub Actions를 사용해봤고 난이도가 낮다고 해서 GitHub Actions를 통해 CI/CD 파이프라인을 최대한 구축해보기로 했다. {레포지토리 루트 폴더}/.github/workflows/ 에 스크립트를 yml 파일로 만들어서 작성해 놓으면 동작하는 방식인데, 처음에는 생소했지만 이것 저것 찾아보고 만져보다 보니 꽤 만족스러운 기능들을 가지고 있었다. 자세한 내용은 다음 포스팅에 기록하도록 하겠다.