We are currently moving from our legacy build server to Jenkins.
In our previous system, we had the following system:
You don't directly build a release version, but you build a "BETA".
After you are satisfied with the result, you can promote the "BETA" to "RELEASE".
For that, you click on the build (the actual pipeline run) and click on a button "BETA to RELEASE".
This button triggers a script to do the actual promotion (the actual steps are irrelevant for this question).
For Jenkins, I haven't found something like that yet. To be precise: I would like to choose one of the successful builds and then click on some kind of button to promote the results of that build to RELEASE. So even if I have build 1.2.0-BETA, 1.2.1-BETA and 1.2.2-BETA, I can choose 1.2.1-BETA and release it to 1.2.1.
What would be a good approach for this?
I would like to suggest the following
We can create a Jenkins pipeline for an Application (Ex: API Services). In this API deployment pipeline, there are many stages,
Get source code from GIT
Restore the dependent libraries
Build the solution & generate the deployment artifacts (with suitable version , ex: Beta 1)
Deploy the artifacts to Dev environment
We have a wait time (ex: 1 day) using a timeout in Jenkins pipeline
Once the dev team validates the build and finds that it is suitable for promotion to QA
they click on Approve
Approved build gets updated with the version (ex: QA-1)
Await QA team approval
Once approved, move to production.
Reference Link: https://jenkins.io/doc/pipeline/steps/pipeline-input-step/
Example Snippet of pipeline code
stage("Validate before Apply") {
timeout(time:30, unit:'MINUTES') {
input 'Are you sure to promote this build to QA?'
}
}
I think that Promoted Builds Plugin is what you need.
Basically, after installing the plugin, you create a job that build your BETA version and in its configuration, you set up a promotion, manually approved, that run your promotion script.
Depending of your need, you maybe configure as well the number of days you want to keep the builds of the job.
Related
My team uses TFS for source control. I recently created a build and a release that we use to push changes to the website to other environments. All work is done in cloud and then released to DEV so that the analysts can verify it works as needed before moving on to UAT and PROD.
If the other programmer and I both check-in files to DEV for the analysts to take a look at BUT one is approved and the other changes are not is there a way to release only the changes that get approved?
You could just use approvals to achieve your requirement in TFS/Azure DevOps Server.
When a release is created from a release pipeline that defines
approvals, the deployment stops at each point where approval is
required until the specified approver grants approval or rejects the
release (or re-assigns the approval to another user). You can enable
manual deployment approvals for each stage in a release pipeline.
For example, a manual approval check on an environment would
ensure that deployment to that environment only happens after the
designated user(s) has reviewed the changes being deployed.
In your case, if you have set up a complete CI-CD pipeline in TFS. Other programmer and you both check-in files to DEV.
First use pull request which let your team review code and give feedback on changes before merging it into the dev branch. This is the first step to verify some code changes are qualified.
Then use a build pipeline to build your source project, you could set up a CI build. It will generate a build for each commit. The build will generate some build artifacts.
Use a release pipeline with some approver to deploy your generated build artifacts to your test environment, product environment. If some stage get rejected, the deploy will fail and no changes released on that environment.
Even though other programmer and you both check-in files to DEV branch, it will trigger different build and different release.
Finally, you could also set up some approval notifications, an email message can be sent to the approver(s) defined for each approval step.
More details please refer our official doc here.
All our Jenkins jobs are configured to build changes on all branches in a repository. There are times where we want to re-run a specific build that ran against a specific commit.
a build fails because some external resource was unavailable and we want to re-run that commit once the resource is up again;
a job depends on an internal package and we need to be able to re-build specific branches to pick up the latest version of that package.
Jenkins' "Build Now" command, however, builds on the branch of the last build. It doesn't let the user choose what branch to build on. In order to rebuild a branch, users have to commit and push a change to that branch.
Is there a plugin that will allow the user to re-run a specific build or choose the branch to build on? If you've used TeamCity, I want the "Re-run with same revisions" feature.
We've tried both the Naginator and Rebuilder plugins. Naginator only lets you rebuild failed builds, but also automatically re-builds failed builds at least once (not desireable). Rebuilder always rebuilds the last commit. It behaves just like the "Build Now" button.
The Rebuild plugin is probably the closest plugin to what you want however as you have found it only will get HEAD and not a specific git revision.
This is an open feature request.
The comment on this question notes the same thing.
All that being so I would still suggest that you should perhaps reconsider the idea of depending on the git revision to drive the outcome of your build. You should want to build the HEAD.
I know this Forum is not to provide strategy's.
Using Jenkins I have set up CI and CD to my Dev,QA and Staging environments. I am stuck up with Rollback strategy for all my environments.
1- What happens if my build fails in Dev
2- What happens if my build fails in QA and passed in Dev.
3- What happens if my build fails in Staging and passed in Dev and QA.
How should I roll back and get things done considering DB in not in place. I have created sample workflow but not sure its an right process.
Generally you can achieve this in 2 ways:
Setting up some sort of release management tool that tracks every execution of your pipeline and snapshots the variables, artifacts, etc... that was used on that exact execution, then you can just run an earlier release of it (check tools like octopus deploy)
If you are using a branch strategy with tags you can parameterize your jobs, passing the tag you wanna build, and build the "earlier tag" if something fails. Check the rebuild option for older job executions.
We run an environment were multiple features are divided into branches. Those branches are configured to a channel in Octopus Deploy.
I would like to see if there is a way to check in a build definition if another build is queued for a branch.
For context - I have a Octopus Deploy step as the last step in our build definition. To deploy the app - it takes approximately 10 minutes. Our build process is also about 10 minutes (it is a big application).
When a team working on one feature checks in - we end up with 2 and 3 builds queued and waiting for each check-in and build to complete.
What I would like to do is have the deploy task run only if there is NOT another build queued for the same branch. This would ensure we don't waste 30 minutes of unnecessary deployments and only deploy the latest code.
What type of build do you use? XAML build or Vnext build. It seems that you use the CI trigger in your build definition, so it will trigger a build each time you do a check in.
VNext build:
You could select the Batch changes checkbox. According to this document,
If you select this option, when a build is running, the system waits until the build is completed and then queues another build of all changes that have not yet been built.
This will combin the changes into one build when you have a lot build queued.
XAML build:
In the build definition, you could use the Rolling builds trigger. This has the same function like the Batch changes mentioned above.
Note:
You also could use this REST API to get if there're builds of a build definition that are queued.
Http method: Get
http://servername:8080/tfs/DefaultCollection/TeamprojectName/_apis/build/builds?definitions=10&statusFilter=notStarted&api-version=2.0
It ended up being easier than I thought - but not exactly what I tried to do in the question.
The Octopus Create Release Task for TFS and VSTS has an option to "Show Deployment Progress". Checking this causes the build definition to wait - periodically receiving feedback from Octopus through the Octo.exe tool.
The deployment for this is actually a wrapper for several deployments (15 separate projects) - so it would take a long time.
Unchecking this option causes TFS to not wait - but send the create release / deploy command to Octopus.
Now this didn't solve my initial question - but Tingting0929-MFST did help me out in that I explored using the TFS Rest API. I wrote a PS script the effectively did what I asked - not deploy if there was a another build queued up for the same branch. I got it working - but it introduced a different problem in that the release notes from TFS and associated changesets / work items were getting swallowed in between releases.
In other words if three checkins came in fairly close separation, the last one would get deployed. Octopus would show only the release notes for last deployment and not the first two.
For those using Octopus Deploy in a feature branch set-up (one project deploying to multiple channels) - this is an option to get you the Continuous Deployment for each channel (branch).
Let's say I have this situation. I have three jobs. Job number one has two manually triggered downstream jobs (deploy to test, deploy to prod for example). Something like this:
I want the deployment jobs (test-job-2, test-job-3) to require a password before they are triggered. How can I solve this with Jenkins?
The only option right now supported by the Build Pipeline Plugin is to have a manually deployed downstream job. But this job starts right after you click on it. I would like to require the user to manually enter some parameters (password for example).
Is there some workaround? I was thinking of using the Promoted Builds Plugin. So the deployment jobs would run in a "dry run mode" - just checking that we have ssh access to the server and some other basic stuff. And then in order to deploy you will have to promote the build.
This approach isn't very nice though. Build pipeline and promoted builds plugins don't interact with each other very well.
This is not exactly what you want, but I guess it would some how solve your problem.
View Job Filters
Using this feature in tandem with a security feature such as the Standard matrix based security can help you create a view that will show different jobs depending on who is logged in.
I use different Jenkins Servers to "complete the pipeline" using Build Publisher job to publish the last part of the pipeline job to the other jenkins. I then pick it up from there. Operations teams have access to the "prod" jenkins system, and developers have access to the "dev" system.