| To give a use case, we have common ci builds for the following:
networking ci build (governs acl rules)
load balancing ci build (governs load balancer config)
platform image ci build (governs centos/ windows images)
developer specific ci build (code compilation). Each of these ci builds have an associated promoted build parameter which when they are successful increments without teams having to manually update dependencies when a check-ins occur to networking, platform or load balancing versions. These ci builds then roll up into a "package build" which generates the build artifact used at deployment time (we build a manifest json file using the artifacts linked to the latest promoted build parameter versions). This is generated every developer check-in and deployment pipelines are then invoked by the new manifest release candidate.
This manifest json then consumes the latest networking, load balancing, platform image using promoted build parameters to pull all the necessary artifacts from each ci build and arrange them as the 1st deployment step in the deployment pipeline. Currently not having the promoted build parameter plugin integrated with the pipeline job type means we cant currently make the package build, currently a freestyle job, the 1st step of the jenkinsfile pipeline job and then trigger other jenkinsfile pipeline jobs from it using promotion stars, as it traverses environments. With the promoted build parameter missing from the pipeline job we are missing the ability to: 1) Associate the promoted build parameters with the pipeline job type as part of the jenkinsfile meaning the pipeline jenkinsfile cant be stored in the code repository and used as the trigger event for the quality assurance pipeline.
2) Trigger a pipeline based on a state change to an artifact repository or another build. Currently we use thoughtworks go for pipelines, which allows us to push the manifest file to artifactory and then poll the repository for changes. The urltrigger plugin could provide this feature as well but it also hasnt been converted to the pipeline job type either meaning we currently have no way to trigger pipelines based on an artifact change. An updated promoted build number could be used to act as that trigger rather than the external artifact.
3) We will want to have a jenkinsfile for each pipeline stage so qa, integration, perf and prod by having association between multiple jenkinsfiles is necessary, the promoted build plugin could potentially do this link, so each pipeline promotes a package (promoted build number) that is allowed to be deployed to the next environment by users. This is particularly useful in continuous delivery when in production environments teams can select a promoted build number to deploy the latest build or trigger a previous promoted build number to roll back by selecting it from the dropdown list. The above points are currently blocking us from moving to jenkins 2.x for pipelines from thoughtworks go and probably preventing many others too. |
