2022. 11. 22. 12:39ㆍ백엔드/Jenkins
"나이틀리 빌드(Nightly Build)를 망가뜨리지 말라!"
이 말은 젠킨스가 나오기 전까지 매일 아침 테스터들을 위해 새로 빌드된 일일 제품 버전을 게시하는 소프트웨어 개발 조직의 기본 규칙이었다.
나이틀리 빌드를 망가뜨리지 않기 위해 개발자가 할 수 있는 최선의 작업은 코드를 커밋(Commit)하기 전에 로컬에서 조심스럽고 성공적으로 빌드해 테스트하는 것이었다.
단, 다른 모든 사람들의 일일 커밋 없이 혼자서 누군의 변경사항을 테스트한다는 전제로,,
이를 해결하기 위해 코스케 가와구치 라는 개발자가 지금의 젠킨스의 초기 버전인 허드슨이라는 오픈소스를 개발하였다.
▶ 자세히 알아보기
젠킨스(Jenkins)는 거의 모든 언어의 조합과 소스코드 리포지토리(Repository)에 대한 CI/CD 환경을 구축하기 위한 간단한 방법을 제공한다.
다른 일상적인 개발 작업을 자동화할 뿐 아니라 파이프라인(Pipeline)을 사용해 거의 모든 언어의 조합과 소스코드 리포지토리에 대한 지속적인 통합, 지속적인 전달 환경을 구축하기 위한 간단한 방법, 각각의 단계에 대한 스크립트 작성의 필요성을 없애주지는 않지만, 사용자가 쉽게 구축할 수 있는 것보다 더 빠르고 더 강력하게 빌드(Build), 테스트, 그리고 배포(deployment) 도구 등 체인 전체를 통합할 수 있는 방법을 제공해 준다.
젠킨스 자동화
오늘날 젠킨스는 온갖 종류의 개발 작업을 지원하기 위한 약 1,400가지의 플러그인을 가지고 있는 선두적인 오픈소스 자동화 서버다. 가와구치가 애초에 해결하려 했던 지속적인 통합과 지속적인 자바 코드 전달, 즉 프로젝트 빌드, 테스트 실행, 정적 코드 분석 시행, 그리고 배포 작업은 사람들이 젠킨스를 사용해 자동화하고 있는 여러 가지 프로세스들 가운데 한가지일 뿐이다.
이 1,400개의 플러그인은 5가지 영역을 포괄하고 있다.
(플랫폼, UI, 관리, 소스코드 관리, 그리고 가장 많이 사용되는 빌드 관리)
젠킨스가 주는 이점
개발중인 프로젝트에서 커밋은 매우 빈번히 일어나기 때문에 커밋 횟수만큼 빌드를 실행하는 것이 아니라 작업이 큐잉되어 자신이 실행될 차례를 기다리게 된다.
코드의 변경과 함께 이뤄지는 이 같은 자동화된 빌드와 테스트 작업들은 다음과 같은 이점들을 가져다 준다.
- 프로젝트 표준 컴파일 환경에서의 컴파일 오류 검출
- 자동화 테스트 수행
- 정적 코드 분석에 의한 코딩 규약 준수여부 체크
- 프로파일링 툴을 이용한 소스 변경에 따른 성능 변화 감시
- 결합 테스트 환경에 대한 배포작업
이 외에도 젠킨스는 500여가지가 넘는 플러그인을 온라인으로 간단히 인스톨 할 수 있는 기능을 제공하고 있으며 파이썬과 같은 스크립트를 이용해 손쉽게 자신에게 필요한 기능을 추가 할 수 있다.
각종 배치 작업의 간략화
프로젝트 기간 중에 개발자들은 순수한 개발 작업 이외에 DB셋업이나 환경설정, Deploy작업과 같은 단순 작업에 시간과 노력을 들이는 경우가 빈번하다.
데이터베이스의 구축, 어플리케이션 서버로의 Deploy, 라이브러리 릴리즈와 같이 이전에 CLI로 실행되던 작업들이 젠킨스 덕분에 웹 인터페이스로 손쉽게 가능해졌다.
Build 자동화의 확립
빌드 툴의 경우 Java는 maven과 gradle이 자리잡고 있으며, 이미 빌드 관리 툴을 이용해 프로젝트를 진행하고 있다면 젠킨스를 사용하지 않을 이유가 없다.
젠킨스와 연동하여 빌드 자동화를 통해 프로젝트 진행의 효율성을 높일 수 있다.
자동화 테스트
자동화 테스트는 젠킨스를 사용해야 하는 가장 큰 이유 중 하나이며, 사실상 자동화 테스트가 포함되지 않은 빌드는 CI자체가 불가능하다고 봐도 무방하다.
젠킨스는 Subversion이나 Git과 같은 버전관리시스템과 연동하여 코드 변경을 감지하고 자동화 테스트를 수행하기 때문에 만약 개인이 미처 실시하지 못한 테스트가 있다 하여도 든든한 안전망이 되어준다.
제대로 테스트를 거치지 않은 코드를 커밋하게 되면 화난 젠킨스를 만나게 된다.
코드 표준 준수 여부 검사
자동화 테스트와 마찬가지로 개인이 미처 실시하지 못한 코드 표준 준수 여부의 검사나 정적 분석을 통한 코드 품질 검사를 빌드 내부에서 수행함으로써 기술적 부채의 감소에도 크게 기여한다.
빌드 파이프 라인 구성
2개 이상의 모듈로 구성되는 레이어드 아키텍처가 적용 된 프로젝트에는 그에 따는 빌드 파이프라인 구성이 필요하다.
예를 들면, 도메인 -> 서비스 -> UI와 같이 각 레이어의 참조 관계에 따라 순차적으로 빌드를 진행하지 않으면 안된다.
젠킨스에서는 이러한 빌드 파이프라인의 구성을 간단히 할 수 있으며, 스크립트를 통해서 매우 복잡한 제어까지도 가능하다.
참고: https://www.oss.kr/info_techtip/show/5231af26-c127-4041-bec9-b6cea244bafb
'백엔드 > Jenkins' 카테고리의 다른 글
| 젠킨스 기본 view ( All ) 바꾸기 (0) | 2022.12.20 |
|---|---|
| Jenkins Gitlab 연동 (0) | 2022.12.15 |
| 내부망 또는 폐쇄망에서 Jenkins 배포 시 체크사항 (0) | 2022.12.15 |
| view 안에 view 만들기 (0) | 2022.12.12 |
| Maven 명령어 (0) | 2022.12.05 |