As we finalize new code for a monthly release, we branch the code, and follow up by creating a new build for the build server and new Release Template in Release Management.
All three of these steps are the same month to month except for file paths and naming conventions that include our internal release number (unique per release). We'd love to make a script to do all this for us: We'd input the desired Release Number, and all three items are generated. I know how to do this for creating the TFS branch and the TFS build definition, so creating the Release Template is the only issue.
Is there an API to programatically create Release Templates in Release Management? (Doesn't need to be a pretty API, I'd be content if I could just copy whatever file defines a previous release with a simple search/Replace of the old Release number to the new one, assuming the Release Templates are serialized to file somewhere.)
There is no API, and there will not be one for the existing RM 2013/2015. The database schema is also quite complicated, so you will most likely not be able to copy a release template via SQL queries.
There may be an API when the redesigned Release experience debuts in TFS 2015 Update 1.
You should not need to create a new release template for every release -- the release template should be a static set of steps necessary to release your software in a repeatable, idempotent fashion. The fact that you want to copy a release template strongly indicates that you are doing something wrong.
Related
I'm trying to understand the process for vNext Builds and Release Management as far as identifying what work items are included.
If I have a build set up on every check-in (each time a work is completed), then each of those Builds will have one work item linked. I can then trigger a Release deployment of those Builds to a QA environment, but then each Release only identifies that one item as being linked - not any others that have been included since our last production release. Since there could be multiple Release Deploys to QA prior to a Deploy to Production, it's confusing trying to filter through all the Releases.
I'm trying to find a good way to see all work items included in Builds/Releases since the last production deployment. Am I misunderstanding how to use this? Should I be using the same Release and just changing the targeted Build each time? It seems like it bases "included work items" off the checked in work-items in between the last build and the current one.
In Release Management, It compares current release with the last release to show the work items included in current release. You only see one work item is because that you have configured TFS to build every check-in and trigger the release for every build. If you trigger a release after two builds, you will see two work items included in the two builds. The latest version of Visual Studio Team Service has support selecting a release version to compare with current version to list the included changes and work items, but this hasn't been implemented into On-premise TFS yet.
So for now, you can create another release definition and link it to the same build to deploy the build to production manually. Then you can track the included work items from this release definition. Or you can create an app/powershell script to read the build version in the production release and then get the included the work items via Rest API.
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.
My company uses Jenkins to do an automated daily build, and FogBugz to track and document our bug fixes. This all works well.
When we've finished testing a Release Candidate and are ready to publish it to the world, we use FogBugz' Release Notes Report feature to automatically generate a text file containing descriptions of what has changed since the previous published release.
That mostly works, but the problem is that our Release Candidate testing can take a month or longer to complete -- so by the time the Release Candidate has passed the testing process and we are ready to publish it, additional bug fixes have been committed into SVN and documented in FogBugz. Therefore, if we then generate a Release Notes report from FogBugz, the report will include descriptions of changes that are not actually present in the Release Candidate we are ready to publish. (*)
The easy solution to the above problem is to generate the Release Notes document on the same day that the Release Candidate itself is compiled; that way the Release Notes document will match the state of the Release Candidate's tested executables. But it is a bit tedious and error-prone to do that by hand for every Release Candidate, so what I'd like to do is have Jenkins do a "Daily Build" of the Release Notes document, the same way it does a Daily Build of the program executables. The Release Notes document would then be kept together with the executables in the Artifacts directory, for use if we decide to publish a Release Candidate based on that day's daily build.
I think that would work really well, but I'm not sure how to get FogBugz to generate a report from a script. Is there a way to do that?
(*) Another approach to this problem would be to create a new Milestone every time we start testing a Release Candidate, but I don't want to do that because it would clutter up our FogBugz database with too many Milestones as buggy Release Candidates were abandoned and new ones were adopted.
I made some headway on this issue... it's possible to use FogBugz' XML API to get XML Release notes. First you have to get a token, as described here.
Then the shell script can execute a command like this one:
wget -OReleaseNotes.xml 'https://fogbugz.mycompany.com/api.asp?token=the_token_value_from_above_goes_here&cmd=search&q=fixfor:MyMilestone&cols=ixBug,sCategory,sTitle,sReleaseNotes'
I suspect there is a more elegant way to do it, and it would be nice if I could get the data in HTML or ASCII format rather than XML, but this is better than nothing.
UPDATED entire question to clarify things.
Software
Team Foundation Server 2010.
Background
Some while ago we migrated our Team Project Collection (= TPC) using Microsoft Team Foundation Server Integration Tools to a new TPC. We wanted to keep our build definitions as well, so we created a new build controller for the new TPC and then manually migrated the build definitions since the tool didn't support that functionality. Once we recreated the build controller, the BuildID was reset. This behavior is understandable since each TPC has its own database where the unique BuildIDs are generated.
The problem is that our assembly versioning scheme uses the BuildID to make sure we can trace an assembly to the related build from TFS. This is why continuing the old BuildIDs (or manually configuring the next BuildID) is essential.
The question
Question is if there’s a setting by which we can define the range of the BuildID so that there’s no overlap with previous builds made by the deprecated Build Controller. For example, if in the old TPC, the last build was ‘499’, then we would like to set the range of the BuildID in the new TPC to [500-99999]".
There are two ways you can solve this problem. The simplest one would be to modify the build workflow, and add an offset to the build id. You can expose the offset as an argument and add it to the metadata, so that it can be modified externally, or you could make it a fixed constant inside the XAML.
A more intrusive solution would be to modify the database directly. In the project collection's database (e.g. Tfs_DefaultCollection), go to the tbl_Build table. The table's primary key is the BuildId. It is an Identity field. All you need to do is change the seed to a new value (e.g. 500); The next build will have the modified build id.
I tried this on my own database, with no observable problems. I suggest you back up your TPC before trying it, just to be safe.
And suggest you simply modify the build to take an offset to the build id.
Hope this helps,
Assaf.
I'm currently working on creating a build template for TFS2010 builds. However, I notice that I'm currently 'spamming' the source control with every change I make to the template (and lots more for all the fixes for those changes).
I wonder what the easiest way is to test the build templates I'm creating?
Is there a way to change the template file and custom activity dlls that doesn't involve checking them in?
I currently have a build controller and agent running on my developer machine, which I'm using to test the template (test = start a build and hope for less errors than last time).
Why is 'spamming' a problem? Anyway, I have a separate Team Project for doing this kind of work, that way I can check in to my hearts content without affecting the developers who need to have a stable build. once I've done my testing I check the template in to the team project(s) used by the developers.
I want to test my builds against the teams latest code-base without having to branch it over to a trial project.
Instead, I do the following:
Create a separate build definition called 'Infrastructure'
clone a production definition
Set the trigger on the Infrastructure build definition to manual.
Set the Infrastructure definitions permissions to allow only [Project]\Build group members to have full control of it.
keeps the notification of broken builds away from the bulk of the team).
Create a separate build process template, called 'Infrastructure.xaml'.
Point the Infrastructure build definition at the Infrastructure process template.
Now when I want to iterate on a new build feature for the team:
Check out the build process template I want to update, and lock it.
Copy the build process template I want to update overtop of the Infrastructure.xaml.
Add my build feature to the Infrastructure.xaml file, and check that in.
Use the Infrastructure build definition to test my changes.
Iterate over 3-4 until I get it right.
Complete the feature and have my changes verified by another Infrastructure team member.
Copy Infrastructure.xaml over the build process template I locked in (1) and check it in.
This still results in 'spam' in the TFS source control, but it keeps the build definition iteration out of the eyes of the team. My build process templates are located out of the main source tree (under the Build Process Templates folder, or in the branches themselves under a 'Core/Build' folder where no-one else on the team is typically paying any attention) so that the team is largely unaffected by it.
#d3r3kk: Why not just branch the template and merge changes back when ready instead of creating copies? That way you can preserve source history in a cleaner way as well.
Ideally, there should be a way to have a build process template that is in progress by having it on your local file system and pointing the build definition to it temporarily. Not sure if something like this exists in later versions of VS/TFS. I haven't seen it available via the UI anyway.