[CI/CD]Jenkins에서 Github Action으로.. (With GCP, Docker) - WABI회고록

들어가기 앞서...

pknu-wap/WABI-BE: 와비 : 부경대학교 소속 및 학생 회비 납부자 확인 서비스 BE (github.com)

 

"WABI" 라는 학생회비 납부 서비스에 백엔드로 참가하면서 CI/CD를 맡게 되었다.

 

[CI/CD]Jenkins를 이용해서 스프링 프로젝트 배포할 때 중요한 점 (With Docker, GCP) - WABI 회고록

이전 회고에선 Jenkins를 사용하여 스프링 프로젝트를 배포하는 과정을 거쳤다.

 

그 당시 Jenkins를 사용한 이유는 다음과 같았다.

1. 널리 사용되고 있다.

2. 높은 확장성을 가지고 있다.

 

합리적인 판단이라고 생각했고 Jenkins를 사용하기로 결정하였다.

 

그런데 막상 사용하고보니 Jenkins는 와비 서비스와 맞지 않았다..

먼저, 인스턴스의 리소스를 먹는 것이 가장 큰 문제였다.

 

Jenkins에서 Gradle의 빌드를 진행하다 보니 Gradle 빌드 역할 수행에 리소스를 먹기도 하고, 서버를 계속 열어둬야 한다는 부담감도 작용했다.

 

무료 인스턴스를 최대한 이용해야 하는 와비의 입장에선 Jenkins 하나는 큰 부담이었다.

 

두 번째로, 높은 확장성이 의미가 1도 없었다.

 

Jenkins엔 다양한 플러그인들이 존재한다. 이로 인해 높은 확장성을 가지고 있으나, 와비에선 필요가 없었다.

 

Github 특정 브랜치에 merge 되면 그걸 빌드하고 배포하면 되는 단순한 파이프라인 때문이다.

 

세 번째로, 결국엔 와비의 CI는 Github가 중심이다.

 

CI를 Github를 사용하다보니 Github 환경과 관련이 높은 Github Actions에 자연스럽게 시선이 갈 수밖에 없었다.

 

그렇다면 Github Actions의 장점은 무엇일까??

제일 제일 매력적이라고 생각했던 서버 구축의 필요성 X

 

Jenkins는 서버를 만들어서 셋팅을 해야 하고 24시간 켜놓았어야 했다.

 

하지만, Github Actions는 빌드와 배포에 필요한 서버를 따로 구축하지 않아도 된다.

 

이게 정말 컸다.

 

두 번째는 Github에 특화된 플랫폼이라는 것이다.

그림 1. Github Actions 페이지

 

따로 Jenkins 매니징 화면에 들어갈 필요가 없고 Github Repository에 Actions 페이지가 존재한다. 

 

여기서 WorkFlow를 만들 수 있다.

 

추가로, 기존엔 application.properties 처럼 환경 변수들을 설정할 땐, 배포 서버 인스턴스 내부의 docker-compose.yml에서 주입을 시도했다.

 

그림 2. Repository Secrets

 

하지만, Github Repository Settings 에서 Repository secrets 해당 변수들을 주입할 수 있다.

 

이런 점들 때문에 Github Actions에서 Jenkins로 넘어가게 되었다.

 

그러면 Github Actions가 뭘까??

GitHub 저장소에서 워크플로를 작성하고 실행할 수 있는 기능을 제공하여 코드 작성부터 테스트, 빌드, 배포까지 개발 프로세스를 자동화할 수 있는 CI/CD 플랫폼이다.

 

Git 이벤트(푸시, PR 등) 기반으로 동작하며, YAML 파일을 사용해 워크플로를 정의한다는 특징을 가지고 있다.

 

Workflow runs · pknu-wap/WABI-BE

여기서 사용한 워크플로를 볼 수 있다.

 

최종적으로 만들어진 CI/CD 파이프라인