업무중, 개인적으로 Jenkins를 사용한 빌드머신을 구성해야 할 일이 있었는데, 한번쯤 이론적인 내용도 포함하면 좋을것 같다는 생각이 들어서

Jenkins에 대해 조사한 내용을 간단히 글로 작성해보았다.

---

🔹 1. CI/CD

Jenkins에 대해 이야기 하기 전, CI/CD에 대한 이야기를 해야 할 것 이다.

CI/CD란, 직역하면 지속적인 통합과 지속적인 전달이다.

약어	본딧말	설명
CI	Continuous Integration	지속적인 통합 : 빌드와 테스트의 자동화
CD	Continuous Delivery	지속적인 배포 : 배포의 자동화

🔶 1-1. Continuous Integration

CI는 모든 개발이 끝난 후 코드 품질을 관리하는 고전적 방식의 단점을 해소하기 위해 나타난 개념으로,

지속적인 통합 (Continuous Integration)이라는 말 그대로 코드 변경 사항이 정기적으로 빌드 및 테스트되어

Repo에 통합되는 과정을 통해 계속 품질을 유지하면서 개발을 진행하는 방법이다.

🔶 1-2. Continuous Integration

CD는 CI의 연장선으로, 이 CI 프로세스를 통과한 코드 버전을 마지막에 배포하는 과정을 말한다.

코드 변경 사항이 파이프라인의 이전 단계(CI)를 모두 성공적으로 통과하면 수동 개입 없이 프로덕션에 자동으로 배포됨으로,

신속하고 능률적으로 사용자에게 새로운 기능을 제공할 수 있는 것이 장점이다.

🔶 1-3. 왜 써야하는가?

혹시.. 지금 빌드를 뽑아주실 수 있나요?

현재 적용되어 있는 빌드가 최신 버전인가요?

빌드 뽑는데 오래 걸릴까요? 바로 배포 가능하신가요?

CI/CD 시스템을 써야 하는 이유는 속도와 효율때문이다.

Quality at Speed가 언제나 소프트웨어 개발의 이상이라면, 오늘날과 같이 다차원으로 끊임없이 진화되고 있는 개발 환경을 고려할 때,

조직들의 가장 큰 과제 중 하나는 시장 변화 및 고객 요구에 신속하고 유연하게 대응할 수 있는 개발안을 구축하는 것이다.

이러한 문제에 대한 중추적인 솔루션인 Agile 문화와 DevOps의 한 부분으로써 CI/CD개념이 출현한 것이다.

◼ 1-3-1. Agile

소프트웨어 개발 방법론의 하나로, 처음부터 끝까지 계획을 수립하고 개발하는 폭포수(Waterfall) 방법론과는 달리

개발과 함께 즉시 피드백을 받아서 유동적으로 개발하는 방법이다.

기본적으로 서비스 기능 테스트 - 릴리즈 - 피드백- 기능 추가 및 개선사항 반영의 짧은 주기를 빠르게 반복하는 방식이다.

개발 프로젝트에 애자일 방법론을 사용하면 적은 기능 단위로 구현하고 결과물을 신속하게 내놓는 사이클을 반복하여

사용자는 최종 완성제품이 출시될 때까지 기다리지 않고 이용할 수 있다.

◼ 1-3-2. DevOps

개발(Development)과 운영(Operation)을 결합해 탄생한 방법론으로,

시스템 개발자와 운영을 담당하는 정보 기술 전무가 사이의 소통, 협업, 통합 및 자동화를 강조하는 소프트웨어 개발 방법론이다.

뿐만 아니라, DevOps는 애플리케이션과 서비스를 빠른 속도로 제공할 수 있도록

조직의 역량을 향상시키는 문화 철학, 방식 및 도구의 조합이기도 하다.

기존의 소프트웨어 개발 및 인프라 관리 프로세스를 사용하는 조직보다 제품을 더 빠르게 혁신하고 개선할 수 있으며,

이러한 빠른 속도를 통해 조직은 고객을 더 잘 지원하고 시장에서 좀 더 효과적으로 경쟁할 수 있다.

📌 1-3-2-1. DevOps의 이점

---

• ✅ 속도
  • 작업 속도가 빨라지면서 시장 변화에 더 잘 적응하고 효율적으로 비즈니스 성과를 창출 할 수 있음
• ✅ 신속한 제공
  • 새로운 기능의 릴리스와 버그 수정 속도가 빨라질수록 경쟁 우위를 차지 할 수 있음
• ✅ 안정성
  • 애플리케이션의 업데이트와 인프라 변경의 품질 보장을 할 수 있음
  • CI/CD 방식등을 통해 변경 사항이 제대로 안전하게 작동하는지 테스트 가능
• ✅ 확장 가능
  • 규모에 따라 인프라와 개발 프로세스 운영, 관리 가능
• ✅ 협업 강화
  • 개발자와 운영 부서간의 협력을 통해 효과적인 팀 구축 가능
• ✅ 보안
  • 자동화된 규정 준수 정책, 세분화된 제어 및 구성을 관리하는 기술 사용 가능

◼ 1-3-3. Agile 과 DevOps의 공통점

공통점	설명
주기적인 릴리스 일정	반복 작업 일정은 다르지만, DevOps와 애자일 방식을 실행하는 이들은 모두 반복 작업과 테스트에 대한 일관된 기반을 바탕으로 새로운 빌드를 출시하는 것을 목표로 한다. DevOps 방식을 사용하는 스튜디오는 한 주에 여러 번 업데이트와 새 빌드를 릴리스하지만, 애자일 방식을 사용하는 스튜디오는 새 빌드에 대한 스프린트가 몇 주에서 몇 달까지 소요될 수 있는 스프린트 모델을 따른다.
고객 가치 제공	애자일 방식은 외부 피드백을 개발 프로세스에 포함시킨다. DevOps는 전체 소프트웨어 라이프사이클에 지속적인 모니터링을 적용하며 포함 범위가 더 넓다.
당면 과제	DevOps 또는 애자일 시스템을 구현하는 과정은 개발 팀에 커다란 문화적 변화일 수 있다. DevOps 방식을 사용하면 기존의 개별 개발 팀과 운영 팀에서 원활하게 협업하는 방법을 새로 익혀야 하지만, 팀 구조와 업무 프랙티스에 대해 유연한 애자일 방식을 사용하면 약간의 조정만 해도 된다.

◼ 1-3-4. Agile 과 DevOps의 차이점

차이점	설명
주기적인 릴리스 일정	DevOps는 프로덕션, 프리 프로덕션, 출시, 출시 후 지원을 아우르는 포괄적 프로세스이지만 애자일은 프로덕션에만 중점을 둔다.
지속적 개선과 모든 것의 지속	DevOps는 제품의 라이프사이클 전반에서 자동화를 활용하여 비효율성을 줄이고 '모든 것을 지속'하는 데 주력한다. 반면에 애자일 소프트웨어 프로젝트 관리 프레임워크는 팀의 결속력과 집중력을 향상하고 고객과 이해관계자의 피드백을 스프린트에 제공하여 지속적으로 개선하는 것을 목표로 한다.
DevOps 툴과 애자일 툴 비교	자동화와 확장에 중점을 두기 때문에 DevOps 라이프사이클 구현의 모든 단계는 툴과 클라우드 서비스에 크게 의존한다. 하지만 애자일에서는 프로세스와 미팅 주기가 더 중요하며 툴은 백로그를 구성하고, 번다운 차트를 계산하고, 생산성을 트래킹하는 계획 단계에서 주로 사용된다.

---

🔹 2. Jenkins

Jenkins는, 이런 CI/CD 환경에서 CI를 지원하기 위한 툴이라고 볼 수 있다.

다수의 개발자들이 하나의 프로그램을 개발할 때 버전 충돌을 방지하기 위해 각자 작업한 내용을

공유영역에 있는 저장소에 빈번히 업로드함으로써 지속적 통합이 가능하도록 해준다.

Jenkins는 원래 허드슨 프로젝트로 개발되었는데,

허드슨의 개발은 2004년 여름 썬 마이크로시스템즈에서 시작되었다.

그러나 2011년으로 접어들면서, 젠킨스란 새로운 이름을 달고 갈라지게 되었다.

웹사이트	jenkins-ci.org
발표일	2011년 2월 2일
프로그래밍 언어	Java
운영체제	크로스 플랫폼
종류	지속적 통합
라이선스	MIT

젠킨스와 같은 CI툴이 등장하기 전에는 일정시간마다 빌드를 실행하는 방식이 일반적이었다.

특히 개발자들이 당일 작성한 소스들의 커밋이 모드 끝난 심야 시간대에

이러한 빌드가 타이머에 의해 집중적으로 진행되었는데, 이를 nightly-build라 한다.

“나이틀리 빌드(Nightly Build)를 망가뜨리지 말라!”는 말은 매일 아침 테스터들을 위해

새로 빌드된 일일 제품 버전을 게시하는 소프트웨어 개발 조직의 기본 규칙이다.

젠킨스가 나오기 전에는, 나이틀리 빌드를 망가뜨리지 않기 위해 개발자가 할 수 있는 최선의 작업은

코드를 커밋(Commit)하기 전에 로컬 머신 상에서 조심스럽고 성공적으로 빌드해 테스트하는 것이었다.

하지만, 이는 다른 모든 사람들의 일일 커밋 없이, 혼자서 누군가의 변경사항을 테스트하는 것을 의미했다.

젠킨스는 정기적인 빌드에서 한발 나아가 서브버전, Git 과 같은 버전관리시스템과 연동하여

소스의 커밋을 감지하면 자동적으로 자동화 테스트가 포함된 빌드가 작동되도록 설정할 수 있다.

🔶 2-1. Jenkins가 주는 이점

개발중인 프로젝트에서 커밋을 하면 Jenkins의 빌드 작업 (Job) 이 큐잉되어 자신이 실행될 차례를 기다리게 된다

코드의 변경과 함께 이뤄지는 이 같은 자동화된 빌드와 테스트 작업들은 다음과 같은 이점들을 가져다 준다.

• 프로젝트 표준 컴파일 환경에서의 컴파일 오류 검출

• 자동화 테스트 수행

• 정적 코드 분석에 의한 코딩 규약 준수여부 체크

• 프로파일링 툴을 이용한 소스 변경에 따른 성능 변화 감시

• 결합 테스트 환경에 대한 배포작업

이 외에도 젠킨스는 500여가지가 넘는 플러그인을 온라인으로 간단히 인스톨 할 수 있는 기능을 제공하고 있으며

파이썬과 같은 스크립트를 이용해 손쉽게 자신에게 필요한 기능을 추가 할 수도 있다.

그 외의 중요한 장점은 아래에 기술했다.

◼ 2-2-1. 각종 배치 작업의 간략화

프로젝트 기간 중에 개발자들은 순수한 개발 작업 이외에 DB셋업이나 환경설정,

Deploy작업과 같은 단순 작업에 시간과 노력을 들이는 경우가 빈번하다.

데이터베이스의 구축, 어플리케이션 서버로의 Deploy, 라이브러리 릴리즈와 같이

이전에 CLI로 실행되던 작업들이 젠킨스 덕분에 웹 인터페이스로 손쉽게 가능해졌다.

◼ 2-2-2. Build 자동화의 확립

빌드 툴의 경우 Java는 maven과 gradle이 자리잡고 있으며,

이미 빌드 관리 툴을 이용해 프로젝트를 진행하고 있다면

젠킨스를 사용하지 않을 이유가 하나도 없다.

젠킨스와 연동하여 빌드 자동화를 통해 프로젝트 진행의 효율성을 높일 수 있다.

◼ 2-2-3. 자동화 테스트

자동화 테스트는 젠킨스를 사용해야 하는 가장 큰 이유 중 하나이며,

테스트 주도 개발 (TDD)로 개발을 진행할 때 반드시 필요한 부분이다.

사실상 자동화 테스트가 포함되지 않은 빌드는 CI자체가 불가능하다고 봐도 무방하다.

젠킨스는 Subversion이나 Git과 같은 버전관리시스템과 연동하여 코드 변경을 감지하고

자동화 테스트를 수행하기 때문에 만약 개인이 미처 실시하지 못한 테스트가 있다 하여도 든든한 안전망이 되어준다.

제대로 테스트를 거치지 않은 코드를 커밋하게 되면 화난 젠킨스를 만나게 된다.

무엇보다 중요한 것은, 이러한 안정망이 제공해주는 든든함이야말로

개발자들이 리팩토링을 통해 문제가 있는 코드들을 적극적으로 제거해줄 수 있는 버팀목이 된다는 점이다.

◼ 2-2-4. 코드 표준(코드 컨벤션) 준수여부 검사

자동화 테스트와 마찬가지로 개인이 미처 실시하지 못한 코드 표준 준수 여부의 검사나

정적 분석을 통한 코드 품질 검사를 빌드 내부에서 수행함으로써 기술적 부채의 감소에도 크게 기여한다.

◼ 2-2-5. 빌드 파이프라인 구성

2개 이상의 모듈로 구성되는 레이어드 아키텍처가 적용 된 프로젝트에는 그에 따는 빌드 파이프라인 구성이 필요하다.

젠킨스에서는 이러한 빌드 파이프라인의 구성을 간단히 할 수 있으며, 스크립트를 통해서 매우 복잡한 제어까지도 가능하다.

---

다음시간에는, Jenkins의 설치와 실제 운용 방법등 간단한 예제를 살펴보도록 하겠다.