이게 CI야? CD야?

✔️ 관련 포스팅 링크입니다.

🧷 [Ubuntu] Java 및 Jenkins 설치 + 스왑 메모리

🧷  [Jenkins] Github 자격 증명 추가 + 웹훅 설정

🧷 [Jenkins] Item 추가 및 Pipeline 작성 + 테스트

🧷 [Jenkins] 스프링부트 프로젝트 CICD 테스트 +삽질 로그

---

🗯️ 들어가기에 앞서

서비스 개발이 완료되면 “배포”라는 과정을 진행 해야합니다.

배포란?
애플리케이션이나 서비스를 개발 환경에서 실제 운영 환경으로 이전하여 사용자가 접근할 수 있도록 만드는 과정을 의미

 

이러한 배포의 과정에는 다음과 같은 과정들이 수행됩니다.

1. 빌드
2. 테스트
3. 배포 환경 준비
4. 코드 배포

즉, 로컬에서 개발한 결과물을 배포 환경(서버)으로 옮기고 실행하는 과정을 의미합니다.

이번 포스팅에서는 이러한 배포를 위한 방법과 종종 들리는 CICD가 무엇인지 알아보도록 하겠습니다.

---

🎭 로컬과 실제 배포 환경

로컬 환경에서 애플리케이션을 개발하고 테스트할 때는 개발자의 노트북이나 데스크톱에서 모든 설정이 완료된 상태로 작업하기 때문에 비교적 편리합니다.

그러나 실제 배포 환경, 예를 들어 클라우드 컴퓨팅 환경(예: AWS EC2)에서는 로컬과는 다르게 아래와 같이 다양한 요소들을 고려해야 합니다.

• 애플리케이션 설정: 스프링부트(WAS)와 데이터베이스 연동, 환경 변수 설정 등.
• 네트워크 설정: IP, 도메인, 보안 그룹, 방화벽 등.
• 리소스 관리: 메모리, CPU, 스토리지 등 클라우드 리소스의 최적화.
• 운영 체제 차이: 로컬과 서버의 OS 차이로 인한 호환성 문제.

이러한 차이점들로 인해 로컬에서 잘 동작하던 애플리케이션이 배포 환경에서 예기치 못한 오류를 발생시키는 경우가 많습니다.

 

또한, 배포 과정에서 수작업으로 설정을 변경하거나 코드를 업데이트하다 보면 실수가 발생하기 쉽고, 이는 곧 서비스 중단이나 버그로 이어질 수 있습니다.

 

이러한 문제를 해결하기 위해 CICD가 등장했습니다. CICD는 소스 코드의 변경 사항을 자동으로 빌드, 테스트, 배포하는 과정을 자동화함으로써, 로컬 개발 환경과 실제 배포 환경 간의 격차를 줄이고, 빠르고 안정적인 배포를 가능하게 합니다.

---

❓ CICD란?

제대로 학습해보지 못했다면 CICD를 하나의 단어로 알고 계신 분들이 종종 있을 것 같은데요.

CI(Continuous Integration)란 지속적 통합을 의미하고,

CD(Continuous Deployment)란 지속적 배포를 의미합니다.

 

사실 개발이 끝난 애플리케이션의 수정이 더 이상 일어나지 않는다고 가정한다면, 배포 환경으로 코드를 옮기고 한번 실행하기만 한다면 끝일 이야기입니다.

 

그러나 소프트웨어를 개발하다보면 버그 수정, 기능 추가 등의 코드의 변경이 자주 일어나게 되고, 이러한 변경에 맞춰 그때마다 사람이 수작업을 한다면 무시 못할 비용이 발생하게 됩니다.

 

이러한 소스 코드의 변경에 맞춰 지속적으로 배포를 하는 과정들을 CICD라고 크게 이해하시면 도움이 될 것 같습니다.

조금 더 구체적으로 알아볼까요?

✅ 지속적 통합 CI

애플리케이션은 혼자서 개발할 수도 있지만, 팀 단위 혹은 대규모의 인원이 모여 하나의 애플리케이션을 개발하게 되는 경우가 더 많습니다.

이런 상황에서 변경된 소스코드를 지속적으로 통합시키는 과정을 CI라고 부를 수 있습니다.

좀 더 구체적인 예시를 들어보자면 CI는 다음과 같은 프로세스가 있습니다.

1. 변경된 소스코드 SCM으로 Commit
2. 소스 코드 변경 감지 (웹훅)
3. 빌드 및 테스트 자동화 (파이프라인)

---

✅ 지속적 배포 CD

위 CI 과정에서 변경된 소스 코드에 대해 통합이 이루어지고, 빌드 및 테스트 결과로 아무런 문제가 없다는 것을 확인할 수 있었습니다.

CD는 이러한 소스 코드에 대해 운영 환경에 배포하는 과정을 뜻합니다.

마치 에디터에서 RUN버튼을 누르는 것처럼 말이죠.

 

저의 생각은 CI와 CD를 굳이 구분지을 필요가 없다고 생각합니다. 왜냐하면 이후에 알아볼테지만 보통 하나의 파이프라인을 통해 이러한 과정이 이루어지도록 만들기 때문입니다.

---

〰️ CICD 툴들은 어떤 것들이 있을까?

CICD를 위한 툴로는 대표적으로 Jenkins가 있습니다. 이외에도 Github Action, Gitlab CI, CircleCI, Travis CI, Bamboo, TeamCity 등 다양하게 있습니다.

제가 접했던 툴로는 Jenkins와 Github Action이 있는데, 다음 포스팅에서는 Jenkins에 대해 주로 이야기 해보려 합니다.

느낌있는 할배...

Jenkins란 소프트웨어 빌드, 테스트, 제공 또는 배포와 관련된 모든 종류의 작업을 자동화하는 데 사용할 수 있는 독립형 오픈 소스 자동화 서버입니다.

 

주로 다음과 같은 특징들이 있습니다.

1. 지속적 통합 및 지속적 배포
2. 간편한 설치
3. 간편한 구성
4. 플러그인
5. 확장 가능
6. 분산

플러그인 기반의 시스템인 Jenkins는 필요한 기능들을 플러그인을 통해 쉽게 확장할 수 있습니다.

이를 통해 다양한 SCM 시스템, 빌드 도구, 배포 시스템, 알림 시스템 등과 통합이 가능합니다.

예를 들어 Git, Maven, Docker, Kubernetes, Slack, JIRA와 같은 도구들과의 통합이 있습니다.

 

또한 Jenkins는 파이프라인(Pipeline)을 사용하여 CI/CD 프로세스를 코드로 관리할 수 있게 해줍니다.

파이프라인은 Jenkins에 지속적인 배포 파이프라인을 구현하고 통합할 수 있도록 지원하는 플러그인 모음입니다 . 코드 형태로 정의되며 크게 선언형과 스크립트형 두 가지 방식으로 정의할 수 있습니다. Jenkinsfile 이라는 파일에 파이프라인을 정의하고 이를 SCM(Git)에 저장할 수 있습니다. 굳이 SCM에 저장하는 이유로는 변경 이력 관리와 코드화함으로써 일관성을 유지하며 재사용성을 높이기 위함이라고 합니다.

---

♾️ 전체적인 흐름을 이해해보자.

마지막으로 CICD 과정이 어떻게 흘러가는지 가볍게 이해하고 이번 포스팅은 마무리 짓도록 하겠습니다.

 

먼저 CICD가 별도로 없는 환경에서 배포에 대한 흐름을 먼저 보겠습니다.

개발자들은 각자의 로컬 환경에서 개발을 진행하고, 변경된 소스 코드를 SCM을 통해 Commit하여 통합합니다.

통합된 코드를 운영 환경에서 배포하기 위해 운영 서버에 접속 후 SCM의 코드를 pull합니다.

pull한 코드를 터미널을 통해 빌드, 테스트를 진행합니다. 그런 다음 코드를 실행하는 것으로 배포를 끝마치게 됩니다.

물론 이러한 과정은 사람의 수작업이 필요합니다.

 

그렇다면 CICD를 구축한 이후는 어떻게 변경이 될까요?

 

로컬 환경에서 SCM으로 코드를 통합하는 과정은 동일합니다.

그러나 특정 브랜치의 변경이 이루어지는 순간 CICD의 구성요소 중 하나인 Webhock을 통해 미리 정의된 Jenkins서버로 HTTP 요청으로 변경 감지를 알립니다.

변경이 감지되는 순간 jenkins 파이프라인이 실행되며 파이프라인에 정의된 과정(pull, build, test, CD)이 자동으로 실행되게 됩니다.

 

이렇게만 보면 이해가 잘 안될 수 있습니다. 그렇기에 다음 포스팅에서는 이러한 과정을 실제로 Github와 EC2환경에서 구축해봄으로써 조금 더 이해할 수 있도록 알아보겠습니다.