Jenkins Plugins for Automating Continuous Delivery
The Release Engineer plug-in allows Jenkins to call Release Engineer as a step in a job and allows Release Engineer to track a Build to a Component. This enables you to utilize Jenkins to orchestrate your Continuous Integration process, while Release Engineer does the heavy lifting of packaging the application stack and deploying it across your Continuous Delivery environments, without the use of one-off script and without the use of any endpoint agents or Jenkins Executors.
The Release Engineer Jenkins Plug-in includes a "Build Engine" object which can be connected to a Jenkins server. Each "Build Engine" can have one or more "Build Jobs" which relate to a particular Jenkins Project on that Jenkins Server. These "Build Jobs" can be linked to one or more components in Release Engineer.
The linking of Components to a Jenkins Build Jobs allows Release Engineer to track which Builds have been performed against which component. The Jenkins plug-in can be set to simply "notify" Release Engineer that a Build has been performed. Since Release Engineer knows which Jenkins Project is linked to which Build Job and which Component is linked to which Build Job, it can track Builds for each Component with an associated Jenkins Project.
Should a deployment be performed, Release Engineer takes the Jenkins Build number into account when determining if a component should be deployed. Even if the Component Version has not changed, a new Build will result in a re-deployment. Jenkins Build Logs can be viewed directly from inside the Release Engineer GUI, minimizing the amount of browser activity required to view Build details. For example, a user can see a Build Artifact on a Target Server and open the details of the generating Build directly from the Server Details page. This information is then tracked in a Continuous Feedback Loop providing a clear map of all artifacts associated to a deployment.
Continuous Feedback Loop
The Release Engineer deployment Continuous Feedback Loop shows all the components which have changed as part of the deployment. Release Engineer integrates with Jira, Bugzilla and GitHub to track the change request and Jenkins Build Number to the Application Component. The display shows the Jenkins Build for each component and which defects are associated with each Application and/or Component. The Feedback Loop allows for instant visualization of the content of the deployment, traced back to the Jenkins Build and Change Request number, regardless of which bug tracking system is used.
Download the Jenkins Plugin from GitHub.
Configuration of the Release Engineer Jenkins Plugin
The basic configuration includes the following:
- Username and Password - Determines security access to the various objects within Release Engineer, including the Applications and Components that are available from the Jenkins Plug-In.
- Target Environment - A Release Engineer Environment contains all of the Servers that will be deployed to.
- Application - A Release Engineer Application contains all of the Components that make up a deployment. It is deployed against an Environment.
- Wait for Deployment to Complete - This tells Jenkins to wait until Release Engineer is finished with the deployment before moving on to the next step in the Job. If this option is chosen, the remaining steps in the Job will only run if the deployment was successful. If left unchecked, Jenkins will continue to the next step in the Job as soon as Release Engineer begins the deployment, and ignore the success or failure of the deployment.
- Use Advanced Version Selection - If this is checked, other options will appear that will allow you to take advantage of the capabilities that are available with Applications within Release Engineer. These include:
- Find Latest Version - If Latest Version is approved, create a new version
- Use Component Selection
- Set Component Attributes
- Set Application Attributes