■ 프로젝트 배경

수동으로 5 개의 VM 인스턴스를 배포하는 기존 방식에 대한 개선이 필요했습니다. 빌드 및 배포 과정에 적으면 5분, 많으면 15분이 소요되었고, 잦은 개선과 배포로 인해 개발팀의 업무 생산성이 저하되었습니다.

■ 프로젝트 목표와 성과

■ 발생 문제 및 해결 방법

1. 다음 두 가지 사안을 중점으로 파이프라인을 설계하였습니다.

   ① 최소 비용으로 자동화를 구축할 수 있는가? ② 설계 및 구축에 들어가는 리소스를 최소화할 수 있는가?

   

   GCP 기술의 높은 호환성을 활용하여 CI 파이프라인을 구성하였습니다. CD를 위해서는 Ansible, Terraform 등과 같은 기술 도입이 필요해졌고, 이는 예상보다 리소스가 많이 드는 작업이었습니다. 개발팀과의 논의 후 1차적으로 빌드 자동화와 패키지 저장을 목표로 업무를 수행하였습니다.

2. 멀티 모듈 환경에 맞춰 상위 모듈을 참조하기 위한 작업이 필요했습니다.

   

   Cloud Build를 통해 빌드를 자동화하기 위해서, 멀티 모듈 구조에 관한 설정이 필요했습니다. <parent> 요소를 사용하여 상위 프로젝트에 대한 하위 Maven 프로젝트의 참조를 정의하였습니다. Cloud Build가 빌드를 할 때, 이러한 종속 패키지를 확인할 수 있도록 Artifact Registry의 확장 프로그램인 wagon을 활용하여 해결하였습니다.

3. 다양한 서버 환경에 따라, 각 환경에 맞는 빌드 파일과 패키지 환경이 요구되었습니다.

   서버 환경이 Maven, npm, Docker 등으로 다양했고 그에 맞는 패키지 구성이 필요했습니다. 평소에 다뤄보지 못한 npm, docker는 빌드 파일을 작성하기에 앞서 빌드 명령어와 환경 구성에 대한 학습을 진행하였습니다. 특히, GCP 깃허브와 공식 문서를 참고하며 각 패키지 환경 별 빌드 파일을 작성하여 성공적인 결과물을 얻을 수 있었습니다.

   

   구체적인 학습과 적용을 위해 개인 GCP 계정에 같은 환경을 구성하여 퇴근 후에도 작업을 진행하였습니다. 실제 서버에서는 회사의 git branch 전략에 따라 release/1.a.b와 같은 브랜치가 트리거되도록 설정하고, 패키지별로 컨벤션을 지정하였습니다. 예를 들어 [패키지명]-모듈명와 같이 새로운 사람이 담당을 해도 쉽게 파악할 수 있도록 컨벤션에 맞춰 패키지를 구성하였습니다.

   • 어려움을 해결하는 과정에서 다음과 같은 지식과 노하우를 습득하고, 블로그에 정리하였습니다.
     • https://cobinding.tistory.com/238
     • https://cobinding.tistory.com/243
     • https://cobinding.tistory.com/242
     • 관련 깃허브: https://github.com/cobinding/gcp-docker-ci-cd/tree/main

■ 프로젝트를 통해 배운 점과 앞으로 활용할 점

1. 실사용자가 있는 서버의 배포 파이프라인을 설계 및 구축하고, 빌드 시간을 단축했습니다.

   기존의 수동 배포 방식은 5개의 인스턴스에 대해 총 60분 이상이 걸렸습니다.(각 인스턴스마다 5분에서 15분 정도 소요) , 각 인스턴스당 1분에서 5분 정도만 걸리며, 전체 과정이 약 30분으로 줄어들었습니다. 이로써 배포 시간을 절반으로 단축하는 성과를 얻었습니다.