회사 업무를 수행하면서 처음 젠킨스라는 도구를 접하게 되었고, 지금까지 업무에서 많은 부분을 도움 받고
있다. 이글을 통해 젠킨스에 대한 구체적인 정의 그리고 내가 작업간에 꼭 알았으면 더 좋았을뻔한 내용들을
정리하기 위해 이글을 작성하게 되었다.
젠킨스(Jenkins)는 소프트웨어 개발 시 지속적 통합(continuous integration) 서비스를 제공하는 툴이다. 다수의 개발자들이 하나의 프로그램을 개발할 때 버전 충돌을 방지하기 위해 각자 작업한 내용을 공유 영역에 있는 Git등의 저장소에 빈번히 업로드함으로써 지속적 통합이 가능하도록 해주는 데브옵스 툴 중 가장 핵심적인 도구이다.
🙋♂️개인적으로 느낀 젠킨스의 장점
코드형 인프라(Infrastructure as Code, IaC)가능하게 해주는 도구병렬처리를 통한 작업 효율성 증가- 다양한
플러그인을 통한 확장성
📑 1. 기본 개념 : 문법
젠킨스에는 파이프라인 이라는 강력한 기능을 제공한다.
파이프라인: CI/CD 파이프라인을 젠킨스에 구현하기 위한 일련의 플러그인들의 집합이자 Job들의 구성
이 파이프라인
이 파이프라인은 1. 스크립트 방식으로 작성할 수도 있고, 2. 서술적 방식으로 작성 할 수도 있다.
그렇다면 이 파이프라인을 작성하는 두 가지 방식에 대해 구체적으로 알아보자.
01. 스크립트 방식의 파이프라인
스크립트 방식의 문법은 젠킨스에서 명령적인 스타일의 로직에 기반하고, 파이프라인 스크립트의 흐름에 따른다.
또한 Groovy 언어와 명령어에 밀접하게 연관돼 있고, 특히 에러 확인과 예외처리 부분에서 의존성이 강하다.
node('working'){
stage('source'){
print("This is Script Pipeline)
}
}스크립트 방식의 파이프라인의 장점
- 대체로 더 작은 섹션과 설명이 가능
- 더 많은 절차형 코드를 사용 가능
- 프로그램을 작성하는 것과 유사하다 = 프로그래머들에게 유리하다
- 더 복잡한 흐름과 파이프라인 설계가 가능하다
스크립트 방식의 파이프라인의 단점
- 대체로 많은 프로그래밍이 필요하다
- 문법 검사과 그루비 언어와 환경에 국한된다(다른 언어 지원 x)
- 서술적 스타일의 파이프라인 보다는 더 복잡하다.
02. 서술적 스타일의 파이프라인
서술적 문법은 주요 영역에서 필요한 상태와 결과를 나타내는 구역으로 잘 나뉘어있고, 로직 자체에 대한 집중은
스크립트 방식보다는 적다. 그에 따라 직관적인 확인과 이해가 가능하다.
Pipeline{
agent{label 'working'} # 어떤 에이전트로 사용할 것인 가
stages{
stage('source'){ # 스테이지 선언
step{
echo 'This is Declarative pipeline' # 스테이지 내 실행 구문
}
}
}
}서술적 파이프라인의 장점
- 필요한 것을 선언하는 것이 유연해 대체로 가독성이 좋다
- 알림과 같이 젠킨스 개념에 대응될 수 있는 섹션이 존재한다
- 문법 확인 및 에러 확인이 쉽다
- 파이프라인의 일관성이 높다
서술적 파이프라인의 단점
- 반복되는 로직에 대한 지원이 적다
- 유연성이 적은 구조이다.
- 복잡한 워크플로우에 작 적용되지 않는다.
정리를 하자면 내 기준에서는 젠킨스의 초심자에 경우에는 서술적인 파이프라인을 통해 가독성이 높고
복잡하지 않은 프로젝트를 진행할때 용이하고 난이도가 다소 있는 프로젝트의 경우에는 프로그래머와 협업하거나 본인이 프로그래머라면 스크립트 방식의 파이프라인을 사용하는 것을 추천한다.
