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.
Related
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.
Is there any options to lock TFS check-ins when the build is failing or three consequent times in Jenkins?
Not totally sure about your meaning of lock TFS check-ins. If you just want a developer checks in changes that break the build. We do not have any build in feature to support this integrate with Jenkins.
However, you can guard some or all of your code base against these problems by creating a gated check-in build definition(TFVC) or pull request(Git) through TFS own build system.
If you are using TFVC, by using Gated build, when developers try to check-in, they are prompted to build their changes. More details please take a look at our official tutorial.
If you are using Git, you could use pull request and branch policy. There is a Build validation setting in branch.
Validate code by pre-merging and building pull request changes
With using both of above method, you could only check in codes/changes when build succeed.
CI system: Jenkins with Jenkins Artifactory plugins, using Pipeline jobs
Language: Java, built with Maven
We have a setup where "release-versions" are supposed to be uploaded to a staging repository, and should be able to be overwritten from consecutive Jenkins builds (for example because of bugfixes in a release/x.x.x branch).
Release versions should not be allowed to be uploaded directly into a release repository, but should be allowed to be promoted into them. They should of course not be allowed to be overwritten from neither a promotion or a direct upload.
In our current setup we have successfully allowed redeploys to staging, and disallowed "re-promotions" to releases. But release artifacts can still be redeployed into a release repository.
Effective permissions for the Jenkins user:
Release repository
Delete/Overwrite: false
Deploy/Cache: true
Annotate: true
Read: true
Staging
Delete/Overwrite: true
Deploy/Cache: true
Annotate: true
Read: true
So, is there a way to:
Disallow deploys (and re-deploys) to the release repository
Allow one promotion per version to the release repository
Disallow "re-promotions" to the release repository
Allow deploys (and re-deploys) to the staging repository
Preferably only using the Artifactory permission settings.
It seems that you are on the right track. As you mentioned, you can "block" the re-deploy (overwrite) by revoking the "delete / overwrite" permissions. for a specific user, or for all of the users in your case. To answer your specific use-case what you will need to do is:
Disallow deploys (and re-deploys) to the release repository
[A1]Create a user for promotion, which will have deploy permissions to the release repository. Other than this user no other user should have deploy permissions to that repository. It should also have read permissions on the staging repository. Please note that Admin users will still have all of the permissions to all of the repositories, but I believe that this should not have any issue.
Allow one promotion per version to the release repository
[A2] Do not give the promotion user (see A1) delete permissions on the release repository. So in a case of an overwrite is being attempted you will receive an error message:
"message" : "Not enough permissions to overwrite artifact 'repoX:path/to/file' (user 'YYY' needs DELETE permission)."
Disallow "re-promotions" to the release repository
[A3] See A2
Allow deploys (and re-deploys) to the staging repository
[A4] Give the Jenkins user delete permissions on the staging repository.
That should do the trick using the Artifactory permission targets.
We're using Jenkins with the Gerrit Trigger plugin so when a changeset is uploaded to Gerrit for review, Jenkins will check if it compiles and post the results.
The workflow happens like this:
A changeset is uploaded to Gerrit
A gerrit hook notifies Jenkins of the new changeset, giving Jenkins certain information such as the Gerrit changeset ID, patch number, target branch, etc.
Jenkins launches a build in the project that is configured to listen to this repository.
When the project is finished building, jenkins reports the result back to Gerrit if the build was successful or not, either +1 or -1. This information is used by the code reviewers in gerrit to help them decide to accept the changeset or not.
Problem: When these builds fail, the Jenkins project is marked "Failing" or "Unstable". This isn't exactly accurate, because the changes that caused the failure are not accepted or merged into the repository yet, they are just newly proposed.
One feature of Jenkins is that it will measure the health of a project based on the ratio of successful to failed builds. If the builds are all working, it will show a "sunshine" symbol but if some are failing then you get a "thundercloud". How do I configure Jenkins so that these verification builds don't affect the stability rating of the project? We need the status for the project to show "sunshine" if the commits that are approved from Gerrit and merged into the git repository builds, regardless of the outcome of builds from changes that are not merged (those changes in Gerrit still pending review). It's ok for the individual build to be red instead of green.
At $DAYJOB, we handle this by using 2 separate build jobs. A commit validation job, which posts +1/-1 on Gerrit changes and which we don't care about build stability. And a build stability/regression job, which runs builds that have already been merged where we do care about stability. We ignore the status color for the commit validation job.
I'm not aware of any way to get the Jenkins plugin to give a -1/+1 vote but always show a status of green. It uses that status when determining what score to give.
Looking for advice on how to handle this scenerio.
We have 3 environments: Dev, QA and Production.
Currently pushing the code to each environment is a manual process, wondering how something like Cruisecontrol or TeamCity could streamline this process.
How can we push to the various environments in an automated way?
How should TFS be setup to make this happen? i.e. master branch, feature branches etc.
Scenerio:
Developer#1 pushes their changes to the Dev and QA servers.
Developer#2 pushes their changes to the Dev and QA servers.
Now we need to only push Developer#1's changes to production.
Should the main branch have only the code that should be going to production?
To control what gets pushed to each environment KMoraz's approach would be the correct one, using branches and merging.
Now, for build and deployment automation the latest setup I've been using is with Team City.
My setup is:
Trunk build: compiles on every commit, runs all unit tests, generates code coverage reports, runs FxCop
Static analysis build: runs nightly against Trunk, executing Duplicate Finder (Team City), ConQAT code clone analysis, StatSVN, and Resharper Code Inspections (Team City)
DEV Deployment (dependency on Trunk build): on every commit, if the Trunk build is successful, the application is automatically deployed to a DEV environment, using MS WebDeploy with config transformations.
QA Deployment: triggered manually through Team City's interface (click of a button), when moving to QA. Deploys the application to the QA server using MS WebDeploy with config transformations.
You would also set up builds for different branches, depending on your needs, especially for branches created for releases of stable versions.
The key part, is having different visual studio build configurations (just as you have "Release" and "Debug", you should have "Dev", "QA", etc), which you should use along with web.config transformations in order to get WebDeploy to configure your environment for you.
That way you'd have different web.Dev.config, web.QA.config transformations, one for each build configuration, with specific settings.
There's an excellent series of posts by Troy Hunt called "You're deploying it wrong!" which guides you through the setup of automated builds and deployments.
http://www.troyhunt.com/2010/11/you-deploying-it-wrong-teamcity.html
It was very useful to me when setting this up.
Now we need to only push Developer#1's changes to production.
-Developer #1 checked-in his code to the Dev branch. After QA verified his changes, now you merge the changes to the Main branch and build a release for production from the Main.
Should the main branch have only the code that should be going to
production?
-Yes. Ideally, production releases should be built from the Main branch.
How can we push to the various environments in an automated way?
-In TFS, a common practice is defining a build defintion per branch and/or build type. Apart from the source and build type, each defintion can also have its own tasks, I.e: run unit tests, publish to certain folders, deploy build artifacts to Lab Management, etc.
ProjectName-Main-Gated
ProjectName-Dev-CI
ProjectName-Dev-Nightly
ProjectName-Test-CI