Enforcing test execution before allowing Git commits - bitbucket

I'm working with BitBucket and VSTS to build a standard CI pipeline.
Development team works on a feature branch. When their work is complete, they merge their code into development branch.
I would like a way to enforce a test execution prior to merging the feature branch into development branch. Ideal situation would be something like this:
The developer creates a pull request.
The code review process is approved.
The developer does SOMETHING, which triggers some process that merges the feature branch with the development branch (feature branch could merge into development branch, or a brand new branch is created with the two branches merged, or something else).
The merged branch is built, deployed, and test executed against it.
Test pass: branch is merged into development branch.
Test fail: feature branch does not merge into development branch (if the branch is already merged into development branch, then the merged commit is reverted out of development branch).
The goal of this process is to keep development branch at a "good" condition.
Typically, the SOMETHING which triggers all this process is the act of committing (or merging) a code into the development branch. The trouble with this process is reverting the code out of the development branch if the tests fail without loosing the code. (It's possible that the merged branch has been deleted at this point).


There is build Pull Request feature in VSTS build, so you can create a new build definition with Build pull requests enabled, then the build will be triggered once a new pull request be created and match the target branch, you can check the build result in pull request in bitbucket.
You can define the policies through checklist: Pull request guidelines for Bitbucket Cloud.
BTW, the VSTS includes branch policies feature, so you can consider using VSTS repository.

Related

jenkins pipeline configuration for starting builds on different branches with gerrit triger

I have recently started to experiment code review using Gerrit Code Review. Now I am trying to create a pipeline in jenkins and I have some issues with building based on a specific branch.
This is what I want to obtain:
I have 2 remote branches: master and develop.
For each new feature I create a local branch and I use git push origin HEAD:refs/for/develop to send the changes to review in order to be eventually merged into the remote's develop branch.
After the changes are accepted and the merge is finalized the code from the develop branch should be built and the result will be deployed to server_1.
At some point the develop branch will be merged into the master branch. The code from the master branch will be built and the result will be deployed to server_2.
I have managed to use Patchset Created event to start the build for the changes that are being reviewed. And probably I will use Change Merged event to start the build based on the develop branch after the changes have been merged
I made the following settings:
Refspec: $GERRIT_REFSPEC:$GERRIT_REFSPEC
Branches to build: $GERRIT_REFSPEC
disabled Lightweight checkout
I tried to use the Ref Updated event to start the build when I push a commit directly into the develop from the local develop branch but it results in a failure. Why is this happening? What settings should I make to make it work?
Also how do I deploy code to the right server based on the current branch name?

Bamboo build tying to undesired BitBucket Commit

Context
I have a BitBucket repo and a Bamboo Plan. The Bamboo Plan is tied to the Bitbucket repo in the "Repository" settings.
The Bamboo Plan "Branch" settings are set to create a new Branch when a new branch is created in the repo.
Issue
When I create a branch, bamboo makes a new branch and starts the build. The first build is tied to the latest commit which came from the original branch. I don't want to associate the new branch build with a commit to the original branch. (It causes more than one build to be associated with the commit.)
Desired Outcome
The build should only tie to new commits in the branch.
Solutions
Pull Request Trigger
I modified my bamboo plan to only trigger new bamboo branches when a Pull Request is created for the repo branch. It did give me the desired outcome. The downside is that commits to the branch will not be executed against the CICD process until a PR is created.
Is there a way to create Bamboo branches only on the first commit to a new repo branch?

No.
I'm sorry there isn't much you can do about this.

How to branch for CI & CD using TFS?

We have Dev, QA pre_prod (stage) and Prod(Trunk) branch.
This is how our process works , please help in improving process to avail CI&CD features using TFS..
Dev changes are merged to QA branch on schedule basis say end of sprint. then published from QA branch. QA team does testing if found any defect , then bug-fix is done in QA branch then get merged with Dev branch.
if QA is done then QA branch is merged with pre-Prod and Acceptance testing is done by client then merged to prod branch and published to client.
if it comes production bug, hot fix is made in pre-prod branch -> published for acceptance testing (acceptance env where QA gets notified) ->all good then then merge to prod branch and publish to client.
hot fix is not merged to QA as it may add other QA ongoing check-ins. since hot fix needs instant fix it goes through Acceptane testing directly where QA also can test .. if all good then get merged to QA branch.
Cons:
1. All development has to be done to give build to QA . so QA is idle. no CI.
2. Another team to do merging between branches. publish it and if error again merging it. resource not free...
how can we implement TFS CI& CD features here ?
CI better works with one branch pattern where check-in will trigger build then QA will test and approve then promote to prod. but here if QA rejects then dev has to fix since it is single branch it will get merge with ongoing daily check-ins and if triggers some more error in QA the this cycle will repeat all the time and features can't be promoted to prod.
Second solution could be to establish branch specific CI & CD as changes are done in individual branch. but here we can't avail the CD feature.... as there is no link between environments ...
third concern is QA needs a stable environment to test all tasks..if in mid new deployment is added through CD then QA testing will get hampered.
please help...and provide your thoughts to it if process needs to be changed...

Run Build after Merging Branch - Team Foundation Server

Is it possible to run an Automated Build when you Merge a Feature Branch into the Development Branch?
When a Developer is done working on their Feature Branch, they will Merge the Feature Branch into the Development Branch. When it is Merge, I would like to fire off an Automated Build, that will run the Unit Tests.
With Continuous Integration, you run the Build when you check in a Changeset. I want to run Continuous Integration when I Merge a Branch into another Branch.

This isn't much different than setting up a build for a normal check in. You would just set up a trigger/build definition on the appropriate branch for the approriate reason. Once the merge is performed into the branch and checked in, this would trigger the build normally.
From my source view see:
KritnerWebsite is trunk, KritnerWebsite-branch is my dev branch.
I complete development/check-ins on the branch, then when done I merge into trunk. At which point the following build definition takes over:
Notice in above the monitored folder for the trigger (in this case gated check in) is my trunk folder in source control.
Hope this helps! :)
FYI a merge isn't actually a "merge" until you check it in and it becomes a changeset. When doing a merge, it actually just gets merged locally - into your workspace. You could technically do a local build at this point, but your build definition won't take over until you actually check it in. I'm not sure why Daniel felt this isn't an answer... as it's the same thing I went through when setting up build definitions for merges - but oh well.

TFS or Teamcity, how to automate deployment to various environments?

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

Resources