젠킨스 작업을 정의하는 방식들

젠킨스 문서마다 작업 정의 방식이 달라 혼란스러웠던 경험을 정리한 글이다. UI 로 정의하는 방식, Jenkinsfile 로 정의하는 방식, 그리고 파이프라인 문법 안의 Scripted 와 Declarative 두 스타일이 왜 공존하는지를 시간 순으로 풀어낸다.

핵심 포인트

플러그인 위키와 오래된 튜토리얼은 대부분 Freestyle project 에서 UI 로 설정하는 방식을 설명한다.
반면 젠킨스 공식 문서에는 그런 UI 화면이 없고 Jenkinsfile 에 작업을 정의한다고만 나온다.
Freestyle project 에서는 Jenkinsfile 을 연결할 수 없다. 별도의 파이프라인 플러그인을 설치하고 Pipeline project 를 만들어야 한다.
파이프라인 기능은 2016년 4월 Jenkins 2.0 과 함께 공식 소개된 것이라, 그 이전 문서에 없는 게 당연하다.
파이프라인 문법에는 먼저 나온 Scripted 방식과 나중에 추가된 Declarative 방식이 있는데, 문서는 Declarative 위주라 혼란이 생긴다.

상세 정리

도입 시점을 솔직히 밝힌다. CI 가 필수라는 데는 오래 동의했지만 급한 일에 밀려 실제 도입은 지그재그 오픈 2년 뒤인 그 전해 여름이었다.
UI 방식의 예로 코드 커버리지 리포트를 모으는 Cobertura Plugin 의 위키 설정 화면을 든다.
원하던 것은 작업을 코드로 정의해 소스와 함께 관리하는 것이었는데, Freestyle 에서 Jenkinsfile 을 연결하는 방법을 못 찾아 한참 삽질했다.
스타일 선택의 실제 결말: 문서는 Declarative 중심인데 그 방식이 원하는 동작을 정의하기에 맞지 않아, 여러 시도 끝에 현재는 Scripted 로 파이프라인을 정의해 쓰고 있다.
GitHub 저장소와 연동해 빌드하려다 젠킨스의 새 UI 프로젝트인 Blue Ocean 을 알게 됐고, 이를 통해 연동 프로젝트를 쉽게 만들었다.
Blue Ocean 에는 파이프라인 편집 UI 가 포함돼 있으며, 거기서 정의한 내용은 Declarative 방식의 Jenkinsfile 로 생성된다.
결론 ①: 새 프로젝트는 무조건 Jenkinsfile 로 만들어 소스에 넣는 게 좋다. 초기 방식은 설정 파일이 소스와 별도로 존재해 관리가 어렵다.
결론 ②: 파이프라인 문법은 대부분의 경우 Declarative 를 권한다. 초보를 위한 편집 UI 도 제공되기 때문이다.
혼란의 원인을 젠킨스가 오래된 프로젝트라 기존 방식을 버리지 못한 채 새 방식을 얹어 온 데서 찾는다.