젠킨스 프리스타일 인터페이스를 통해 하나의 잡을 만드는 일은 어렵지 않았으나 여러 개의 잡을 연관된 소프트웨어 배포 파이프라인으로 묶는건 꽤나 어려운 일이였다.
젠킨스의 기본 기능 중 하나의 잡이 완료됐을 때 특별한 다른 잡을 시작시키는 기능이 있지만 워크스페이스와 변수 등을 두 잡 사이에 전달하는 것은 괘나 어려웠고, 특별한 플러그인이나 트릭이 필요했다.
젠킨스2는 마스터 노드가 다시 시작했을 때 잡이 이전 지점부터 다시 시작되는 기능이다. 젠킨스2의 이러한 기능을 위해 호환되는 플러그인은 상태를 직렬화해 마스터 노드가 다시 시작하면 이를 이용해 이전 상태를 복구하는 기능을 지원해야 한다.
이전 젠킨스에는 재실행 기능이 존재하지 않았는데 사용자나 프로세스가 종종 특정 상태에서 멈춰버려 로그를 통해 어떤 상태에서 멈췄는지 알아내거나 프로세스를 처음부터 시작시켜야 됐다.
이전 사용자는 웹 기반의 인터페이스에 종속돼화면에서 적합한 장소를 찾아 버튼과 입력 영역에 오타 없이 데이터를 입력하는 과정이 필요로 했다.
이번 저번에서 각 잡에는 고유의 워크스페이스가 있어 소스 코드 다운로드, 빌드 및 필요한 작업을 진행했다. 이런 방식은 각 잡의 환경을 고립시키고 데이터 덮어쓰기를 방지하는 방식을 통해 잘 동작했다. 하지만 여러 잡을 묶는 경우네는 해결하기 어려운 비효율적인 결과를 낳기도 했다.
아티팩트를 저장소에 저장해 실행할 때마다 이를 가져다 쓰는 방식도 각각의 잡에 많은 설정이 필요한 일이였고, 좀 더 효율적 방식은 잡 사이에 워크스페이스를 공유하는 방식이나 전 버전은 잘 동작하지 않았다.
대안으로 사용자는 특별한 워크 스페이스를 정의하여 이곳을 가르키는 변수를 정의하거나 플러그인을 통해 구현해야만 했다.
기존 젠킨스에서는 웹 기반 폼에 의존해 데이터를 입력하고 XML 설정파일 형태로 홈 폴더에 저장할 수 있었다. 이런 구현 방식에서는 여러 잡의 실행 개요를 보기 힘들었고 이에 익숙치 않은 사용자에게는 젠킨스 설정과 잡의 정의를 이해하기 위해 화면을 돌아다니며 폼에 입력된 값을 살펴보고, 전역 환경 변수를 조사하는 등의 과정이 필요했다.
기존 젠킨스의 잡 소스는 엑스엠엘 파일이였고 이는 웹 인터페이스를 통하지 않으면 읽기 어려울 뿐만 아니라 틀리지 않고 수정하기가 상당히 힘들었다. 또한 환경 설정 파일은 소스 코드와 같은 장소에 저장되지 않게 설계돼 두 가지는 각각의 방식으로 관리 괬다.
결과적으로 가독성이 떨어지게 됐고 변경 사항을 추적하는 플러그인이 있었지만, 일반적으로 소스 코드를 추적하는 것처럼 쉽지 않았고 추적을 하려면 여전히 젠킨스 애플리케이션이 필요했다.