Jenkins와 CI/CD

이미지 출처 - https://www.epnc.co.kr/news/articleView.html?idxno=206817

최근 서비스를 빌드하는 데 대해서 많은 고민을 한 것 같다.

처음으로 빌드 자동화 도구인 Jenkins를 알아보며, 회사 프로젝트 내에서 기존 빌드 구축 방법과 달리 도입해보려는 시도도 하려 한다.

 

그래서 나도 개인적으로 스터디가 필요하여 이론 -> 실습 순으로 정리해보려 한다.

우선 Jenkins 공식 홈페이지에 대한 내용을 정리해보려 한다.

Jenkins는 아래의 홈페이지로 접속할 수 있다.

 

https://www.jenkins.io/

Jenkins

 

 

Jenkins란?

 

jenkins 공식 홈페이지에서는 Jenkins를 이렇게 이야기하고 있다.

"선도적인 오픈 소스 자동화 서버인 Jenkins는 모든 프로젝트 구축, 배포 및 자동화를 지원하는 수백 개의 플러그인을 제공합니다. "

공식 사용자 문서를 들여다보면 Jenkins는 소프트웨어 구축과 배포와 관련된 모든 종류의 자동화를 사용하는 독립형 오픈 소스 자동화 서버라고 설명하고 있다.

 

Jenkins는 도커(Docker, 가상환경)을 통해 설치하거나, JRE(Java Runtime Environment) 환경에서도 독립 실행형으로 실행할 수 있다.

 

쉽게 설명하자면 Jenkins는 소프트웨어를 개발할 때 지속적으로 통합(CI, Continuous Integration) 할 수 있는 툴이다.

개발할 때 개발자가 일일이 작업하던 환경을 자동적인 명령어나 스크립트로 실행할 수 있도록 지원할 수 있는 환경을 제공해준다.

 

Jenkins의 이점

- Jenkins는 간단한 CI(Continuous Integration) 서버로 사용하거나, 프로젝트의 지속적인 전달 허브로 사용할 수 있음

- 정적 코드 검사 및 테스트로 소스코드의 품질을 향상해줌

- 플러그인을 통하여 거의 모든 도구와의 통합 및 확장이 가능함

 

이러한 이점과 더욱 세부적인 커스텀을 통해 무한한 확장성으로 Jenkins를 구성할 수 있다.

 

Jenkins를 보다 보니 CI(Continuous Integration)라는 개념이 나왔다. 그리고 이와 같이 함께 나오는 CD(Continuous Delivery or Deployment)라는 개념도 있다. 이 또한 알아보자.

 

 

CI(Continuous Integration, 지속적 통합) 

CI라는 개념은 빌드와 테스트를 자동화해서 공유 저장소에 병합시키는 프로세스를 말한다.

여러 명의 개발자가 하나의 공유 저장소를 사용할 때, 빌드와 테스트의 공통 작업이 이루어진다.

이때 빌드/테스트 자동화부터 코드의 일관성을 제공하기 때문에 통합한다는 용어를 사용한다.

 

CD(Continuous Delivery/Deployment, 지속적 전달/배포) 

CD는 CI의 빌드/테스트를 통해 정상적으로 수행됨을 확인하면 배포를 수동으로 하느냐 자동으로 하느냐 두 가지로 나뉜다.

 

- 지속적 전달(Continuous Delivery)

: 프로덕션 배포를 위한 상태를 검증하고, 검증이 완료되면 배포 자체는 수동으로 실행한다.

 

- 지속적 배포(Continuous Deployment) 

: 프로덕션 배포를 위한 상태를 검증하고, 검증이 완료되면 배포 자체는 자동으로 실행한다.