작업 DSL 플러그인 대 파이프 라인 플러그인

작업 DSL 플러그인 대 파이프 라인 플러그인

---

Job DSL Plugin 과 Pipeline Plugin 의 주요 차이점은 무엇입니까?

1. 둘 다 프로그래밍 방식의 일자리 창출 방법을 제공합니다.
2. 앞으로 나아갈 때 사용하는 것이 가장 좋으며 그 이유는 무엇입니까?
3. 둘 다 비슷한 기능을 가지고 있다면 다른 사용 사례가 있습니까?
4. Jenkins 2.0은 코드로서의 파이프 라인에 초점을 맞추고 있기 때문에 job-dsl에 미래가 없거나 파이프 라인 플러그인이 Job DSL 플러그인의 다음 단계라는 의미입니까?

---

나는 둘 다에 대한 광범위한 경험을 가지고 있습니다. 간결한 대답은 Job DSL이 훨씬 오랫동안 존재했으며 Jenkins를 "코딩"하기위한 Netflix의 오픈 소스 솔루션 이었다는 것입니다. 이를 통해 Jenkins 작업 스크립팅에 논리와 변수를 도입 할 수 있으며 일반적으로 이러한 작업을 사용하여 특정 프로젝트에 대한 일종의 "파이프 라인"을 형성합니다. 이 플러그인은 작업 템플릿 및 스크립팅을 활성화하는 일반적인 방법으로 상당한 관심을 받았습니다.

Jenkins Pipeline (2.0)은 전적으로 DSL을 기반으로하는 Jenkins 작업의 새로운 화신으로, Job DSL의 가장 일반적인 사용이었던 단일 파이프 라인을 채우기 위해 여러 작업을 결합 할 필요가 없습니다. 원래 Pipeline DSL은 Job DSL이 제공하는 많은 기능을 제공하지 않으며 위에서 언급했듯이 Job DSL을 사용하면 Pipeline 작업을 생성 할 수 있으므로 파이프 라인을 정의하는 데 함께 사용할 수 있습니다.

오늘날 IMO는 Job DSL을 사용할 이유가 거의 없습니다. Pipeline은 Jenkins 파이프 라인 스크립팅을 위해 Jenkins가 지원하는 메커니즘이고 Job DSL의 많은 기능을 충족하거나 능가했기 때문입니다. 새로운 플러그인은 기본적으로 Pipeline 용으로 개발되고 있으며 Jenkins 개발자가 Pipeline과 통합하도록 권장하지 않는 플러그인도 있습니다. 그리고 Pipeline에는 몇 가지 장점이 있습니다.

• 파이프 라인 은 작업 자체 이기 때문에 Job DSL과 마찬가지로 파이프 라인을 사용하여 작업을 "시드"할 필요가 없습니다 . Job DSL을 사용 하면 다른 작업 을 생성 하는 스크립트 일뿐 입니다.
• Pipeline을 사용하면 매개 변수화 된 수동 입력 단계와 같은 기능을 사용하여 파이프 라인 내에서 로직 미드 스트림을 지정할 수 있습니다.
• Job DSL에 포함될 수있는 로직은 작업 자체 생성으로 제한됩니다. 파이프 라인을 사용하면 작업 내부에 직접 로직을 포함 할 수 있습니다.
• Job DSL은 예를 들어 Build Pipeline Plugin을 사용하여 기본 전달 파이프 라인을 만드는 것이 훨씬 더 어렵습니다 . 파이프 라인을 사용하면 파일이 더 작아지고 구문이 더 짧아집니다. 그리고 Job DSL을 사용하여 Pipeline 작업을 생성하는 경우 Jenkins Pipeline에서 즉시 사용할 수있는 템플릿 기능을 고려할 때 더 이상 큰 가치를 보지 못했습니다.

마지막으로 Jenkins Pipeline은 현재 Jenkins의 가장 널리 사용되는 기능입니다. 아웃 확인 젠킨스 세계 2,016 의제를 하고 약 나타납니다. 세션의 50 %는 파이프 라인을 포함합니다. 작업 DSL의 경우 없음.

---

내 느낌은 둘 다 사용하는 것이 이상적인 접근 방식입니다. Pipeline은 작업을 코드로 포함하는 새로운 기본 Jenkins 기능입니다. 그러나 Jenkins를 처음부터 빌드하는 경우에도 해당 작업을 생성해야합니다. 즉, Jenkins는 100 % 진정으로 스크립트를 작성하고 코드로 빌드 할 수 없습니다.

할 수있는 일은 JOB DSL을 사용하여 모든 작업의 ​​스켈레톤 구조를 구축 한 다음 작업 구현을 위해 파이프 라인을 사용하는 것입니다. 이렇게하면 생성 될 초기 시드 작업을 제외하고 Jenkins를 100 % 스크립팅 할 수 있습니다.

아마도 결국에는 파이프 라인을 사용하여 Jenkins (보안, 구성 및 플러그인)를 완전히 제어 할 수있을 것입니다. 하지만 그때까지는 DSL과 Pipeline을 사용하는 것이 좋은 접근 방식이라고 생각합니다.

---

매우 제한된 경험을 바탕으로 한 예비 답변 :

• 각각은 다른 Groovy DSL을 사용합니다.
• Job DSL은 Groovy 스크립트에 따라 다른 작업을 생성하는 방법을 제공합니다. 따라서 X 관련 작업 세트 (예 : 파이프 라인)를 원하는 경우 하나의 Job DSL 작업을 생성하고 스크립트를 작성하고 해당 작업을 실행 한 다음 해당 X 작업과 해당 작업을 생성 할 작업을 갖게됩니다. . 이때 직접 생성 한 작업 만 실행되고 해당 작업으로 생성 된 작업은 실행되지 않습니다. OOTB, 이러한 작업이되어 있지 멀티 모듈 메이븐 작업의 메이븐 모듈이 숨겨져있는 방법을 숨겨,하지만 난 뷰를 만들고 거기에이 작업을 부착하는 방법은 적어도이 이해합니다.
• Pipeline DSL은 내가 시도한 두 가지 매우 다른 환경에서 무기한으로 중단됩니다. : '(내가 이해하는 것처럼 이것은 알려진 굉장한 버그입니다. 검색하면 이에 대한 공개 버그 티켓을 찾을 수 있습니다. 생성 한 파이프 라인 작업을 실행하는 사람은 실제로 파이프 라인을 실행하지만 Job DSL과 같은 작업을 생성하지 않습니다. 따라서 파이프 라인 작업을 실행하는 트리거는 정의 된 작업을 단순히 업데이트하는 것이 아니라 파이프 라인을 실행하기위한 트리거입니다.
• 다운로드 수를 보면 파이프 라인이 더 널리 사용되는 것으로 보입니다. 물론 Pipeline은 Jenkins 2.0의 기본 기능으로 최근 다운로드 급증을 설명 할 수 있습니다. Jenkins의 관리자는 확실히 당신이 그것을 사용하기를 원합니다 .

요약하자면 Job DSL의 DSL은 파이프 라인을 형성하는 작업을 생성하기위한 것이며 Pipeline Plugin의 DSL은 파이프 라인 자체를 정의합니다.

그리고 귀하의 질문에 답하기 위해 : 파이프 라인은 향후 더 광범위하게 지원되어야하며, 나에게 더 간단 해 보이며 (작업은 메타 작업이 아니라 작업 임), 더 많은 기능 (워크 플로 포함)이있는 것 같습니다. 앞서 언급 한 둠의 굉장한 버그를 발견하고 수정 / 해결 방법을 찾을 수없는 경우가 아니면 사용하겠습니다.

---

지금까지 여기에 언급되지 않은 중요한 차이점이 하나 있습니다. 바로 테스트입니다. job-dsl을 사용하면 DSL 코드를 SCM에 커밋하기 전에 테스트 할 수 있습니다 . https://github.com/sheehan/job-dsl-gradle-example- 로컬 테스트 스위트를 DSL 코드에서 실행할 수 있습니다. 코드가 실행되기 전에 Jenkins에서도 마찬가지입니다. 내가 아는 한 네이티브 파이프 라인 접근 방식에는 이에 상응하는 것이 없습니다.

참조 URL : https://stackoverflow.com/questions/37657810/job-dsl-plugin-vs-pipeline-plugin