Deployment Automation on GitLab CI
Projects |
SVN 형상관리 + Jenkins/Hudson 수동 빌드 환경을 GitLab CI 자동 빌드와 S3 아티팩트 관리 체계로 전환하고, 10개+ 서비스(Spring Boot, Ant 데몬)에 동일한 패턴으로 적용한 프로젝트입니다.
담당: 파이프라인 설계 및 구현, 배포 스크립트 작성, SVN→GitLab 이관 (배포 실행과 서비스 확인은 각 서비스 담당 개발자)
1. Overview
기존 SVN 형상관리 + Jenkins/Hudson 수동 빌드/배포 환경을, GitLab CI 자동 빌드 + S3 아티팩트 관리 + 서버 배포 스크립트(prepare/deploy/rollback) 체계로 전환했습니다.
서비스 유형(Spring Boot fat JAR, Ant 데몬 JAR+lib)에 관계없이 동일한 CI/CD 패턴을 적용할 수 있도록 설계하여 10개+ 서비스에 확장 적용했습니다.
What Changed and What Did Not
| 구분 | 내용 |
|---|---|
| 바꾼 것 | 빌드 자동화, 아티팩트 버전 관리, 배포 절차의 스크립트화, 롤백 경로 확보 |
| 바꾸지 않은 것 | 배포를 실행하는 주체. 개선 전후 모두 각 서비스 담당 개발자가 배포를 수행합니다 |
새로운 승인 체계나 배포 판단 권한을 만든 것이 아니라, 반복되는 빌드/전송/명령 작업을 CI와 스크립트로 옮긴 것이 이 프로젝트의 범위입니다.
2. Problem Statement
| 문제 | 영향 |
|---|---|
| SVN 기반 운영 + Jenkins/Hudson | 당시 조직에서 브랜치를 나눠 개발하는 흐름이 정착되지 않았고, 빌드 서버도 노후화된 상태 |
| 수동 배포 (SCP + SSH) | 배포 작업이 길고 휴먼 에러 빈발 |
| 롤백 체계 부재 | 장애 시 복구 시간 길어짐 |
| 배포 이력 관리 부재 | 어떤 산출물이 배포됐는지 확인할 근거 없음 |
SVN 자체가 브랜치와 병합을 지원하지 않는 것은 아닙니다. 당시 조직의 운영 방식상 브랜치를 활용한 개발 흐름이 자리잡지 않았던 것이 실제 문제였습니다.
3. Architecture
Deployment Flow
CICD Pipeline Diagram
Deployment Strategy
| 환경 | 트리거 | 방식 | 이유 |
|---|---|---|---|
| TEST | test 브랜치 push | 자동 (SSH + SCP) | 빠른 검증 |
| PRD | main 브랜치 push | S3 업로드까지 자동, 배포는 담당 개발자가 실행 | 금융권 안전성 확보 |
4. PRD Deployment Scripts
서버에 설치된 셸 스크립트로 S3 아티팩트를 관리하며 배포합니다:
| 스크립트 | 기능 |
|---|---|
prepare-release.sh | S3에서 최신 아티팩트 다운로드 + 현재 버전을 backup에 백업 |
deploy-release.sh | 프로세스 중지 → 재시작 → Health Check |
rollback.sh | backup에서 이전 버전 복원 → 재시작 |
# 1. S3에서 다운로드 + 현재 버전 백업
./prepare-release.sh
# 2. 프로세스 재시작
./deploy-release.sh
# 3. 문제 발생 시 롤백 (backup에서 복원)
./rollback.sh
5. Applied Service Types
Type A: Spring Boot (Gradle, fat JAR)
| 항목 | 내용 |
|---|---|
| 빌드 | Gradle bootJar |
| 산출물 | 단일 JAR (타임스탬프 태깅) |
| 런타임 | Amazon Corretto Java 21 |
| 배포 단위 | 단일 JAR 교체 → 재시작 |
Type B: Ant Daemon (JAR + lib)
| 항목 | 내용 |
|---|---|
| 빌드 | Ant jar |
| 산출물 | JAR + lib/ (의존성 20~30개) tar.gz 패키징 |
| 런타임 | Amazon Corretto Java 8 |
| 배포 단위 | tar.gz 풀어서 JAR+lib 교체 → 재시작 |
6. SVN to GitLab Migration
git-svn을 이용해 커밋 이력을 유지하면서 Git으로 전환- 기존 Jenkins/Hudson 빌드를 GitLab CI로 대체
- 브랜치 전략 도입:
main/test/develop
7. Results
| 지표 | Before | After |
|---|---|---|
| 형상관리 | SVN | GitLab (브랜치 전략 도입) |
| 빌드 | Jenkins/Hudson (수동) | GitLab CI (push 자동) |
| 배포 절차 | SCP + SSH 수동 명령 | 스크립트화 (prepare / deploy / rollback) |
| 롤백 | 절차 없음 | backup 기반 복원 경로 확보 |
| CI/CD 대상 | 0개 | 10개+ 서비스 |
| 아티팩트 | 관리 없음 | S3 타임스탬프 버전 보관 |
배포/롤백 소요 시간은 측정 기준(시작/종료 시점, 대상 서비스)을 정리한 뒤 추가할 예정이라 대표 지표에서는 제외했습니다. S3 타임스탬프는 산출물 버전을 식별하기 위한 것이며, 실행 주체까지 연결한 완전한 배포 추적 체계는 아래 SSM 연계와 함께 정리 중입니다.
8. In Progress: Migrating to SSM-based Deployment
현재는 담당 개발자가 서버에 접속해 배포 스크립트를 실행합니다. 이 접속 자체를 없애기 위해 SSM Run Command(send-command) 연계를 구현하고 있습니다.
목표 흐름:
빌드 산출물 생성
→ S3 보관
→ 개발자가 GitLab download Job 실행
→ CI가 SSM으로 서버에 산출물 준비
→ 개발자가 deploy Job 실행
→ CI가 SSM으로 서버의 배포 작업 수행
전환이 완료되면 테스트/운영 모두 개발자가 서버에 직접 로그인할 필요가 없어집니다. 배포를 수행하는 주체는 그대로이고, 서버 접속과 반복 명령만 CI로 옮기는 것이 목표입니다.
대화형 세션(start-session) 대신 send-command를 선택한 이유는, 비대화형이라 CI에 적합하고 어떤 Document를 어느 인스턴스에 실행했는지 명령 단위로 이력이 남기 때문입니다.
이 항목은 구현 진행 중이며, 아직 운영에 적용된 상태가 아닙니다.
9. Used Skills
- GitLab CI/CD (.gitlab-ci.yml)
- Amazon S3 (아티팩트 버전 관리)
- AWS Systems Manager - Run Command (전환 진행 중)
- Bash (배포 스크립트: prepare / deploy / rollback)
- Gradle (Spring Boot) / Ant (레거시 데몬)
- SSH / SCP (TEST 자동 배포)
- Spring Actuator (Health Check)
- EC2 (Amazon Linux 2)
- git-svn (SVN → GitLab 이관)
- ECR (CI Runner 이미지 관리)
