I have multiple branches and for every one i have specific build process.
How do i set up gated build process for specific branch?
example
Development branch
-> fast for developers
build process this has main intergation tests
Release branch
-> checkin before production.
contain load testing and records steps contains automated UI tests
Now for my development i want to run tests every time when developer commits changes. but i do not want release build to run every time.
How do i set this up?
You need to have two separate build definitions: One building your 'Development' branch & one building your 'Release' branch.
Both can base on the same Build process template and their differences are:
Dev-build targets in 'Workspace' the path of your development branch - Rel-build targets the path of your release branch
(This is you main question) Trigger = "Gated check-in" for your Dev-build, Trigger = "Manual" (or some other) for your Rel-build
Rel-build will probably be tasked with additional tests.
A basic walkthrough on how to setup a build definition in TFS2010 can be found here
Related
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).
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.
I have one build controller and it has 4 build agents in it. When I run more than one build at a time it queues the build. Why it doesn't run 4 builds parallel? Is there any settings that I should change?
I am running TFS 2012.
running gated checkin
it also runs all the tests after the build is done.
Thanks for the help!
This is 'by design'. From Use a gated check-in build process to validate changes
Each gated check-in build definition can have only one running build at a time.
This is necessary to preserve the logic coherence of you version control.
If this is slowing your dev organization, you have many options (some are in the doc linked):
Change from Gated to Batched gated
Have multiple Build definitions (mapped on different portions of you sources)
Minimize the checks during build
Feed more resources to the Build server
We have 1 build controller and 2 build agents. One build agent (tfsbuild01) is on the build controller machine (tfsbuild01). Another is on a separate machine (tfsbuild02).
We have 2 branches:
Main
8.0
and 3 build definitions
Main (Gated Checkin)
8.0 (Gated Checkin)
Main Coded UI Tests (Scheduled for 12PM daily)
If someone queues up an 8.0 build and a Main build at the same time, the builds are correctly distributed across the two build agents and they build at the same time.
If the Coded UI Tests are running (which take an hour) and someone tries to check in to Main (which is Gated), the Main build sits in the queue until the Coded UI Tests finish. How can I get concurrent builds in the same branch working?
Tags configuration on all build definitions look like this:
This is really a horses for courses question. You have your build of your asset and your instance tests mixxed up. I would recommend that you push your CodedUI tests off to an environment and only run the tests that can be executed from code, and ideally unit tests only, with no instance on the build box.
To execute your codedUI tests you should create a release pipleine in Release Management and also set up your release environment as a Lab environment. This way you can have quick builds and then ouch the longer validation out of that pipeline.
http://nakedalm.com/building-release-pipeline-release-management-visual-studio-2013/
http://nakedalm.com/execute-tests-release-management-visual-studio-2013/
This will free up your build agents and hopefully make your environment slicker.
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