🔹 젠킨스란?
Jenkins는 “CI/CD(지속적 통합·지속적 배포)”를 자동화하기 위한 오픈소스 서버다.
즉, 코드를 푸시하면 → 자동으로 빌드 → 자동 테스트 → 자동 배포까지 수행하게 해주는 자동화 도구라고 보면 된다.
🔹 왜 필요한가?
1) 사람이 직접 빌드/배포하면 오류가 자주 발생함
- 환경 설정 잊음
- 특정 명령 누락
- 로컬 환경과 서버 환경 차이 발생
젠킨스는 스크립트로 자동화하여 반복 작업을 표준화함.
2) 코드 병합 시 문제가 빨리 발견되지 않음
- 팀원이 여러 명이면 매번 모든 테스트를 수동으로 돌리기 어려움
→ Jenkins가 코드가 바뀔 때마다 자동 테스트 수행 → 실패 시 알림
→ 품질 보장 + 버그 조기 발견
3) 배포 속도를 크게 단축
- 커밋 → 자동 빌드 → Docker 이미지 생성 → 서버 배포까지 자동
→ 개발자가 배포에 시간을 낭비하지 않음.
🔹 Jenkins의 핵심 기능
🔸 CI(Continuous Integration)
- GitHub/GitLab/BitBucket과 연동
- 푸시될 때마다 자동 빌드 + 자동 테스트
- 문제 발생 시 슬랙/이메일로 알림
🔸 CD(Continuous Delivery/Deployment)
- 테스트 통과 → 스테이징/운영 서버에 자동 배포
- Docker, Kubernetes, AWS EC2, ECS 등과 연동
🔸 파이프라인(Pipeline) 스크립트 지원
예: Jenkinsfile
pipeline {
agent any
stages {
stage('Build') {
steps { sh './gradlew build' }
}
stage('Test') {
steps { sh './gradlew test' }
}
stage('Docker Build') {
steps { sh 'docker build -t myapp .' }
}
stage('Deploy') {
steps { sh 'docker-compose up -d' }
}
}
}한 파일(Jenkinsfile)로 전체 자동화 흐름을 정의할 수 있다.
🔹 Jenkins 동작 구조
- 개발자가 Git에 푸시
- Jenkins가 Webhook 또는 Poll로 변경 감지
- 빌드 서버에서 코드 빌드(GRADLE/MAVEN)
- 테스트 실행 (JUnit 등)
- 성공 시
✔ Docker 이미지 빌드
✔ Docker Hub/ECR 등 푸시
✔ 도커 컨테이너 자동 재배포
✔ or Kubernetes Rolling Update - 실패 시
✘ 배포 중단
✘ Slack/Email 알림
→ 확실하게 “품질 + 배포 자동화”를 보장한다.
🔹 Jenkins vs GitHub Actions vs GitLab CI
| 구분 | Jenkins | GitHub Actions | GitLab CI |
|---|---|---|---|
| 설치 | 직접 서버 설치 필요 | 클라우드에서 제공 | GitLab 포함 |
| 비용 | 무료 | 무료 (제한 있음) | 무료+유료 |
| 유연성 | 매우 높음(플러그인 많음) | 중간 | 중간 |
| 관리 비용 | 높음 | 낮음 | 낮음 |
| 적합 | 회사 자체 Infra, 복잡한 파이프라인 | 개인 프로젝트, GitHub 사용 | GitLab 기반 팀 |
→ Jenkins는 자유도와 확장성이 매우 높고, 기업 환경에서 많이 사용됨.
🔹 언제 Jenkins가 특히 좋은 선택인가?
- 사내 서버·온프레미스 환경을 운영하는 경우
- 복잡한 MSA 환경 (다중 모듈 빌드 + 다중 배포 타깃)
- Docker/Kubernetes와 맞춤형으로 강하게 연동할 때
- Slack, Jira, Grafana 등과 고도화된 파이프라인이 필요할 때
- GitHub Actions 같은 SaaS를 사용하기 어려운 보안 환경인 경우
🔹 요약
- Jenkins = 빌드/테스트/배포를 자동화하는 CI/CD 서버
- Git 푸시 → 자동 빌드/테스트/배포
- Jenkinsfile로 자동화 파이프라인 관리
- 대규모 기업·온프레미스 환경에서 선호됨
- 플러그인 생태계가 매우 크고 자유도 높음
꾸준한 공부만이 답이다