Jenkins와 Github Action

0. 둘 다 실행하면서..

Jenkins는 초기에 설정한 node (Worker, Slave)에서 Build 및 Deploy를 하는데,
Github Action은 워크플로우를 실행할 때 마다 VM을 생성-동작-제거 하는 것으로 이해하고 있습니다.

따라서, 이왕 이렇게 된 거, 비교해봤습니다.

---

1. Jenkins 개요

📌 특징

• 오픈소스 CI/CD 도구
• 온프레미스 또는 클라우드 환경에서 직접 관리 가능
• 마스터-슬레이브(worker) 구조 사용
• 플러그인을 통해 확장 가능
• 인프라 구성과 유지보수가 필요

🏗️ 실행 방식

• Jenkins는 마스터 노드와 에이전트 노드(Worker/Slave)를 사용
• 기본적으로 에이전트(Worker) VM을 미리 준비해두고 사용자가 지정한 빌드 환경에서 파이프라인을 실행
• 에이전트는 Jenkins Master와 연결된 상태에서 대기하다가, 실행 요청이 들어오면 그 환경에서 바로 실행됨
• 워크플로우가 끝나도 에이전트는 계속 유지되며, 다음 빌드에서도 사용 가능

📌 장점

✅ 완전한 커스터마이징 가능 (플러그인, 독립적 인프라 관리)
✅ 온프레미스 환경에서 강력 (기업 내부망에서 실행 가능)
✅ 다양한 SCM 및 빌드 툴과 연동 가능

⚠️ 단점

❌ 초기 설정과 유지보수가 복잡 (서버 운영 필요)
❌ 인프라 비용 발생 (에이전트 유지 필요)
❌ 구축 방식에 따라 스케일링이 어렵거나 추가 비용이 발생할 수 있음

---

2. GitHub Actions 개요

📌 특징

• GitHub에서 제공하는 CI/CD 서비스
• GitHub 리포지토리와 깊게 통합되어 있음
• 이벤트 기반(푸시, PR, 이슈 등)으로 자동 실행
• 클라우드 기반의 일회성 실행 환경 사용

🏗️ 실행 방식

• 워크플로우가 실행될 때마다 새로운 VM 또는 컨테이너가 생성됨
• 실행이 끝나면 해당 VM은 삭제됨
• 기본적으로 GitHub에서 제공하는 실행 환경(Hosted Runner) 사용
• 필요하면 자체 Runner를 사용할 수도 있음 (온프레미스에서 실행 가능)

📌 장점

✅ 초기 설정이 간편 (별도 서버 운영 불필요)
✅ GitHub과 강력한 연동 (이벤트 트리거 활용 가능)
✅ 클라우드에서 자동 스케일링 (실행 환경을 직접 관리할 필요 없음)

⚠️ 단점

❌ 워크플로우 실행할 때마다 새로운 환경이 생성되므로 캐싱 최적화 필요
❌ GitHub의 제한 (무료 사용량 초과 시 요금 발생)
❌ 커스터마이징 및 플러그인 지원이 제한적

---

3. Jenkins vs GitHub Actions 비교

비교 항목	Jenkins	GitHub Actions
설치 및 운영	직접 설치 및 관리 필요	GitHub에서 자동 제공
실행 방식	미리 설정한 에이전트에서 실행	매 실행마다 새로운 환경 생성
인프라 관리	직접 서버 운영 필요	GitHub이 실행 환경 관리
확장성	플러그인으로 확장 가능	GitHub Marketplace 이용 가능
비용	자체 인프라 운영 비용 발생	GitHub Actions 요금제 적용
CI/CD 설정	자유로운 설정 가능	GitHub 리포지토리에 최적화
사용 용도	엔터프라이즈 환경에 적합	GitHub 기반 프로젝트에 최적

---

4. 어떤 경우에 사용해야 할까?

🔹 Jenkins가 유리한 경우

• 기존에 온프레미스 환경에서 CI/CD 운영 중인 기업
• 커스터마이징이 중요한 프로젝트 (플러그인 활용)
• 자체적으로 에이전트 관리를 할 수 있는 환경
• GitHub 이외의 다양한 SCM과 연동해야 하는 경우

🔹 GitHub Actions가 유리한 경우

• 빠르게 CI/CD를 구축하고 싶은 경우
• GitHub을 중심으로 프로젝트를 운영하는 경우
• 클라우드에서 실행하며 인프라 관리를 피하고 싶은 경우
• 자동 스케일링이 필요한 경우

---

5. 결론

Jenkins

• 온프레미스 환경과 복잡한 CI/CD 구축이 필요한 경우 적합

GitHub Actions

• GitHub 중심의 프로젝트에서 간편한 CI/CD를 원할 때 적합