I'm creating build definitions in vsts.
I'm using $(Rev:.r) as my build number format.
I want to be able to use this scheme separately for each branch.
For example if i have 3 branches, master/develop/feature
Master builds start from 1,2,3
Develop builds start from 1,2,3
Feature builds start from 1,2,3
Remember that Build number format can be configured at the Build definition level.
You can simply create a separate build definition for each branch.
Build Definition for master
Build Definition for develop
Build definition for feature
With the Build#Format as $(Rev:.r)
So theres an update in a recent release that mitigates this to some degree.
https://learn.microsoft.com/en-us/azure/devops/release-notes/2018/sprint-142-update#add-custom-build-counters-to-your-builds
With this, you can use a build number format like $(Build.SourceBranchName)-$(rev:r)
if you have 3 branches test1,test2,test3, you build nos will be like
test1-1
test1-2
test1-3 and so on
test2-1
test2-2
test2-3 and so on
test3-1
test3-2
test3-3 and so on
Related
I'd like to be able to trigger a build in TFS Build when a developer tags in Subversion. I'd also like to use the tag number as part of the build and release name. Is this possible in TFS right now?
There is no this built-in trigger for building a repository type of subversion in TFS.
You could first get the event (a developer create a tag in svn) from SVN. Not sure how to do this in SVN, should be something like the service hooks in TFS. Then trigger a build in TFS 2017 using REST API. How to do this please refer: How to trigger a build in TFS 2015 using REST API
As for how to use the tag number as part of the build and release name, see below:
Create custom build number during build
With Team Build you can update the build number at any time during the
build by outputing "##vso[build.updatebuildnumber]1.2.3.4" to the log
during the build.
You can see the full list of logging commands here https://github.com/Microsoft/vso-agent-tasks/blob/master/docs/authoring/commands.md
This will update the build number & name.
The down side that you have run into is that you can no longer use the
auto-incrementing number that you have been trying to use. You need to
come up with the version number yourself, and then pass it back using
the output above.
Source
Add two more related blogs:
vNext Build Awesomeness – Managing Version Numbers
Generate custom build numbers in TFS Build vNext
We use a nice $(date:yyyy.MM.dd)$(rev:.r) build number format in our day-to-day agile sprints. However, the release must be numbered with a simpler 1.0.0.rev schema.
Ideally, I would like to give the build number as a variable, which would be automatically expanded in the "queue build" dialog, where it would be possible to be overriden. How can it be done?
I tried moving the $(date:yyyy.MM.dd)$(rev:.r) format to a variable, and use that variable in the general tab, and got error 400.
You could directly use Environment variables such as Build.BuildNumber /BUILD_BUILDNUMBER
Using this just equals to the name of the completed build. You can specify the build number format that generates this value on the General tab.
If you just want to generate custom build numbers like 1.0.0.rev schema in TFS Build vNext. You can take a look at below blogs:
Generate custom build numbers in TFS Build vNext
Managing vNext build Version Numbers
This is very simple.
1) Just create a Powershell script like this
$FinalVersion=Some-Function-To-Calculate-Version
$BuildDefName = $Env:BUILD_DEFINITIONNAME
Write-Host "##vso[build.updatebuildnumber]$($BuildDefName)-$($FinalVersion)"
2) In your vNext build definition, for "Build number format" just set it to anything. It doesn't matter because the Build Number will be overwritten.
3) In the same vNext build definition steps, add the first step as a Powershell step, and set your script from step 1 to be executed. You can later customize if you want to pass variables in order to calculate your build number.
4) Queue your build and see the results.
I'm currently using Team Foundation Server 2015 (Update 2) and wanting to use the new build definitions and release management and wondering what the best practice is around creating build definitions when using multiple branches.
We have multiple branches and there will also be multiple solutions in each branch (for this example i'll call them WinApp.sln, WebApp.sln & MobileApp.sln).
Our project branches are something like the following...
Project
Dev
Main *** This is our development branch for new features
Updates
1.2 *** This branch is used for any bug fixes for version 1.2
Main
Releases
1.1
1.2 *** Current release branch that will be deployed to customers
Using the new build definitions in TFS 2015 is it best to create a new build definition for each of the branches or each of the applications in each branch.
For example I create the following build definitions:
AppName.Dev.WinApp
AppName.Dev.WebApp
AppName.Dev.MobileApp
AppName.Updates.1.2.WinApp
AppName.Updates.1.2.WebApp
AppName.Updates.1.2.MobileApp
AppName.Release.1.2.WinApp
AppName.Release.1.2.WebApp
AppName.Release.1.2.MobileApp
And then that would flow through to the release management by having release definitions like the following:
AppName.Dev
AppName.Updates.1.2
AppName.Release.1.2
Each release definition will have artifacts added for each of the 3 solution builds.
Or would it be better to just have 1 build definition for each branch?
Would be interesting to know what other people are doing in similar situations.
Previously with the xaml based builds, we had multiple build deifnitions because whenever we released a new build template, we did not want the older release build definitions impacted, hence we maintained multiple build definitions. We also maintained that for the sake of the version the build gets.
But, with the new vNext builds in place there is no way we can have a previous version of a task available to use once we enhance a task and upload it to the TFS all build definitions start using the latest task and there is no way(other than renaming a task) by which we can select a task of older version. So, I think it would be of no use to maintain multiple build definitions, as the build definitions are going to get updated if a task is updated.
There is a case where we require to maintain a version for a specific release and if the number depends on the builds triggered, in that case we'll have maitain different build definitions becuase our patches cannot have the latest version number.
One more reason to maintain different build definition is to escape from the headache of remembering what tasks were used in a specific release previously.
So all in all I'll go with different build definitions to avoid versioning chaos and to maitain integrity of a release build definition.
When it comes to release,we bind a build definition to a release definition. So, again to have a smooth bug fix and update, different release definition for each build definition has to be present.
Our TFS 2013 admins have given us one build definition to build our solution and run all unit tests and they are not willing to create any more build definitions. We are following feature branch strategy and would like to use this build definition for our gated builds. I am trying to find how to use this one build definition with multiple branches.
I know, I can add all branches to Source settings and build them whenever a check-in is made. But I want to find out, if there is any way to add branches to Source settings, but only compile the solution that has been checked in. For example if we add 5 solutions to the Source settings, we want to compile only the solution that has changed rather than all 5 solutions.
You will need to setup an incremental build that only builds the solutions that have changed.
Ideally you will want to setup a build for every branch. You would still use the one build template given to you, but you would define the work-spaces and behavior differently for each branch depending on your needs. However if you do not have that option you can still implement what you are trying to do.
For example if you only want to build the solution that has changed you will set up your build to be an incremental build like the following:
In the "Process" tab update the "Items to build" section to any *.sln or *.*proj
In the "Workspace" section, select only the source control paths of each branch if setting up a build for every branch or select the entire source if that is how you have to do it ($/).
Change the build to an incremental build by changing the Build Process Parameters on the "Process" tab - CleanWorkspace=None
Tag one of the build agents, so that it is the only one used for these incremental builds. Set the build to only use this tagged agent. It is important that the same build agent or set of agents is used for the builds if incremental builds are to work.
We use TFS source control and have two build controllers (one VS2010 the other VS2012). We use the default build workflow template bar a few custom changes.
As we have many branches, how would we go about changing the workspace based on the desired branch?
I was thinking of adding a parameter for the branch ($\oursourcecontrol\branches\main) and then just passing it as a variable in to the get workspace part of the workflow.
Or is there a better way of doing it?
You currently can't and it is really a shame. It would completely break the Trigger support for CI and Gates checkins. You can use the TFS Community Build Manager to quickly clone and adjust build definitions to support multiple branches though.
What you could do, is to fetch more than you need (say $/Sourcecontrol/Branches/*) and then use a string-replace on any path parameter (like solutions to build, test settings file etc) to point them all to the correct solution. You'll probably need to do some templating like {BRANCH} so that you can easily replace these tokens.
The Git build template does support this on a Git repository, but you'd need TFS 2013 to make use of server side Git support.
I mapped the server path in the Repository tab at higher level that TFS branches are contained. Cloak rest of the branches not required for Get sources step except the branch to be built. And create variable to pass the branch name, check allow at queue time. Use this branch variable in build steps to make the build definition work for all the branches. You may need more than one variable based on your branches structure in TFS.