I am preparing to move my team's source control from VSS over to TFS 2008.
This is for an asp.net website, and I am currently using a combination of nant scripts and Cruise Control to do all of the builds and deployments.
I've been trying to wrap my head around the best way to architect TFS build to do the same thing I'm doing with NANT and Cruise Control, but I can't determine the best approach.
Here are my requirements:
When code reaches a certain point, I manually apply a label to it.
This labeled code needs to be built and deployed to any of our 25 different Dev, QA, or production environments.
Any of these 25 environments can be on any current or past labeled version of the application.
I need to be able to deploy any labeled version of the application to any of the environments.
I'm currently accomplishing the above using NANT to perform the build, and using Cruise Control to just pass in command line options for which environment(s) to build and deploy. I have a Nant config file with a list of all of my environments, and an associated label each environment should currently be using. This file gets manually updated whenever a new label is created.
I know the approach I'm using for NANT probably won't be the same as with Team Build, but has anyone done something similar with Team Build and could share how you accomplished it?
Labeling in TFS is much more robust than in VSS. When you create a label, you can create based on a changeset, date, workspace version, heck even a different label. (BTW, I was grabbing a link and came across this post that you might find relevant.)
By default, a Team Build will build from the latest version of code in source, but you can override the "CoreGet" target in a build to build a specific version. Aaron Hallberg (a.k.a. TFS's John Skeet) shows an example here.
see 4.
I haven't personally had this difficult of a requirement, but I've done something similar. When you queue the build, you can pass in any number of parameters in a couple important ways, 1) through the response file and 2) at queue time (simple example here). In either case, two parameters could be which environment and which label/version number. At my current project, I have continuous integration turned on, so when code in a workspace is checked in, the current code is automatically labeled, pull the specifics for my drop location from the response file, then deploy to the respective location.
Given the fact that you have ~25 environments and n number of versions/labels, you could build a simple GUI that reads the current labels through the TFS API and lets you pick which version to build to a particular environment.
To answer the question, the way I addressed this was to use a combination of a custom build task, cruise control, and msbuild.
The custom build task allowed me to get the latest version from a specific branch and label.
Cruise control allowed me to pass in specific information for a specific build to MSbuild, using a config file, but initiate the build from a UI.
msbuild was used like normal, however it was called from cruise control, and the custom build task did most of the work.
Related
We have upgraded from TFS 2013 to TFS 2017, One feature we are trying to implement that we had in 2013 was the ability to have a custom build number. the previous method we had a file called BuildVersion.XML which during the first build step would read the major,minor, and revision and name the build with that build number + 1 on the revision. It would then change then checkout and update the revison number and check in the new version. I know that there are steps where people update the AssemblyInfo. The issue is that not all our code is .net apps. we also now have SSIS Packages, Cordova iOS/android apps, angular sites, aws Lambda functions with node.js which do not have the concept of AssemblyInfo. is there an easy way to implement this?
You can do exactly the same thing in Team Build in TFS 2017.
You can update the build number from any task by calling:
Write-Verbose -Verbose "##vso[build.updatebuildnumber]1.2.3.4"
Add a PowerShell task and add an inline script to read from your file and update the build number with the above.
You can then have additional scripts that use the build number any way you need to version your application.
You can see the full list of logging commands here
https://github.com/Microsoft/vso-agent-tasks/blob/master/docs/authoring/commands.md
You can use my VSTS TFVC tasks to interact with source control, though I do not recommend it. I built these tasks for clients of mine who were doing exactly what you are doing.
Instead of relying on a file in source control it would be a much better solution to pass the BuildNumber from the Build Definition along to the build, have one of your first steps update the files on disk with the correct version number then run your build.
If you manipulate files during the build and check them in you run the risk of inconsistent numbering when you scale up to multiple build agents, it's hard to use in combination with parallel builds and build variable multiplexing and it becomes notoriously hard to do Gated Checkins and Shelveset builds. Plus, it limits your options to move to Git in the future.
I'm starting to dive into TFS 2012 and I have a basic understanding of the tiers and how build servers, controllers and agents work and how different build scripts can have different configurations and projects.
However, one of the things I'm struggling with is a requirement for our source control solution that says that I need to be able to prove a particular changeset or shelfset produced a particular build. That is, given a particular binary, I can point to a release changeset that generated that binary. I should also be able to point to the test changeset that was merged into the release branch. The idea here is not just a separation of duty, but validating that because the release and test changesets are identical, no code was injected into a project by a code reviewer.
I've read one blog post that talks about "Binary promotions" -- would that concept be useful in my situation? I'm having a hard time finding how this binary promotion is set up in TFS.
Deployment
Out of the box TFS doesn't really support deployments, it can deploy to 1 location on build which often is a test server (think lab management). TFS 2012 has built in support for Azure deployments, but they still happen at the end of a build and the build artifacts cannot be automatically deployed to a new location.
You could modify the build template to allow to release to different locations, but that would still be a fresh build for every environment and not true binary promotions.
TFS does, however, have a concept of build quality and actually fires off events when this quality is changed. TFS Deployer is a 3rd party tool that hooks into the quality change event and can execute powershell scripts. This means with a simple change of a dropdown value you can automatically kickoff a script that releases to any environment you want. You can customize the build quality list (per team collection) to be a list of environments (dev, uat, staging, production etc) which the script then figures out where to release the specific build to.
VS2012 also has some nice improvements to web deploy which means deployment configurations are stored in source control with the project, which in theory means they'll be available in the drop folder for TFS Deployer to make use of.
I don't believe TFS keeps a history of build qualities, which means you can't really use the build quality history to maintain a list of what is deployed to which environment. You could fairly easily record this information as part of the deployment script though. Or at the very least add a custom summary node to the build with information about the release.
TFS2012 does have the ability to mark a build as deployed as part of the Azure deployment functionality, you mark tfs deployer builds as deployed using a script but it doesn't feel very useful.
Octopus Deploy is another project that's worth checking out, and could be used instead of TFS Deployer if your build template creates NuGet packages. It requires a bit more control over the production hardware as you need to install agents on each environment to handle releases, but it solves a lot of other issues with deployment.
Versioning
Once you have a nice consistent way of automatically releasing that people don't bypass, you can look at enhancing the build template to inject the build version, or changeset number as the assembly version for anything built as part of that automated build. There's a number of different ways to do it and plenty of blog posts and tools to help you achieve that.
Alternatively you could just use automatic assembly versioning ([assembly: AssemblyVersion("1.0.*")]) to give you the date/time the build occurred, which ends up like 1.0.1234.123 where 1234 is something like the days since jan 1st 2000, and 123 is the minutes since midnight (my specifics may be wrong here).
If you're deploying websites, then I highly recommend injecting the current build version into the html somewhere. This way you can check what version a website is running without needing access to the bin directory. It can also be appended as a querystring to css/js file imports to ensure no browser caching occurs between versions.
Thoughts
Personally I'm hoping Microsoft realise that the xaml build workflows are trying to do too much and that they split the different concerns (build, test, deployment...) into different scriptable parts. Of course that would not be until the next major release of TFS which is years away. Although with Team Foundation Service they are trying to iterate a lot quicker, so they may actually extend the Azure deployment stuff into something more useful in the nearer future.
I am working with Visual Studio 2012 .NET 4.5 ASP.NET MVC 4 project that uses TFS for source control and TFS Build for continuous integration (CI).
I want to create functionality that on each check in the build number gets updated prior to the CI build is kicked off.
From research it seems that a custom activity can be created and integrated in TFS 2010 build template.
I have also seen examples of this can be achieved with MSBuild task.
I haven't done work in this area before, so I am wondering which is the better approach or the recommended approach based upon the options open to me? In general when would I use MSBuild tasks as oppose to custom activity? For example, I will be looking to run FxCop and StyleCop against check ins also in the future, so I would like a common approach to this.
In the case of incrementing the build number, I'd vote for the TFS Build Activity so that the implementation is not tied to your msbuild implementation. This allows you to easily apply the TFS workflow activity to any number of branches without tying it to the branches directly. In addition, it keeps your MSBuild project files clean of the task so that it isn't mistakenly executed on developer machines.
Holistically, I'd say that you need to take a variety of factors into account when deciding between MSBuild and Workflow activities:
1 - Does MSBuild support the functionality out of the box (like Code Analysis/FxCop)?
2 - Does the build step need to run on developer boxes as well as servers (StyleCop/FxCop)?
3 - Does the build step need to interact with the TFS API or source control directly (checking out/in a version file for incrementing)?
4 - Are you going to change build job schedulers later to something free (for example, Jenkins)?
It's the combination of these things that determines the implementation of any given tool integration in my book. I'd implement FxCop, StyleCop and any other tool that should be run on a developer box build via MSBuild. I'd implement build steps such as version incrementing, bin-placing and CI deployment invocation (for example, deployment of a SharePoint webpart as a post-build step) via a Code Activity or some scriptware.
In 2009, there was a SO question on the same topic.
I'm wondering if later versions of Team Foundation Server are better at longer build pipelines. Refer features of Jenkins, TeamCity, ThoughtWorks' Go (my employer).
The visualizations of the build pipelines are important to me, as well as the notification about individual stages passing or failing. That and the eminent clone-ability of say a 'trunk' pipeline into one for a release branch as that branch leaps into being.
Secondly, a personal holy-grail is the CI server storing its config in the SCM that's holding the buildable thing itself, and even picking up on the creation of branches silently to provision new pipelines; Can TFS be configured to store the CI definitions/scripts in its SCM side rather than its accompanying SqlServer?
TFS build consists of three components:
The build definition - stored on the SQL server data tier.
The build workflow - a XAML file stored in the source control.
The supporting MSBuild scripts - usually contains user defined actions, also stored in the source control.
As the build progresses, you can see visualization of the build steps and you also get a different log for the main build and the MSBuild output.
The build definition in TFS is merely a collection of build settings, similar to CC.Net's config file and TeamCity's build configuration tab which both stored on the file system as well. Assuming there's a backup plan on the database you don't really need to store the build defintions on the source control, but if you must it's possible by exporting the tbl_BuildDefinition table.
The TFS Power Tools adds cloning functionality for build definitions.
There's no OOTB support for provisioning build definitions from a new branch though it's fairly feasible using the TFS-API.
Bit late to the party, but just don't bother with TFS if you want advanced build pipeline automation. It simply doesn't cut it.
I have used Jenkins and TFS both extensively. Tfs is just. pure. crap. Here's why.
No down/up stream build.
No piepline/orchestraion build. (like jenkins)
Obscure ways of adding build steps and falls back to using MsBuild.
Slow and still polls the source control.
Ties you to MsTest.
And please don't point me to "Oh look you can do everything if you write a custom activity". I'm not wasting time doing development for a closed source, sub-par platform. If I am going to contribute something, it's to a FREE. OPEN SOURCE platform.
Currently we are using StarTeam to perform the build as well as versioning. we planned to migrate startteam to TFS2010. We have some script for perform the build. i wanted to change this script according to my requirement. i gone through the TFS but i had lot more confusion.
in StarTeam, we will get a files from "Ready to Build" label and perform the build. In TFS, how we are going to get a files from TFS? What concept should i use to get a files and perform the build? i have gone through the lot of commands like get, check-in, checkout etc..
If we use "tf get" command, we can get all the files from TFS but i have a clarification on that. shall i get all the files from TFS for every build? i hope, this is unnecessary headache.. correct me if i am wrong..
how we perform the build in TFS? i have read some types of build such as manual, gatedcheckin, Continuous Integration and schedule.
Is there any relationship between branch and build activities?
In TFS, What is the meaning of Workspace?
As said, many questions in one. Hope this helps along the way:
A workspace is a mapping between the server and a local storage,
similar to checkout in Subversion, view in ClearCase, etc.
"TF get" normally only fetches those files that have changed since
last update. You can force it to fetch everything - and sometimes
have to - but its not normally done.
Team Build is the recommended system to build with when using TFS. It can take some time to get into (Windows Workflow-based), but is quite powerful. There are default process definitions that set up the most common actions for you.
By default, you can't control whether to build by setting a certain label, but you can define that only this label should be used when builds are triggered. Labels in TFS work a little differently compared to other VCS, though, so maybe there's an 'opportunity' to re-think your build process along the way. If you're set on using a label as before, you'll need to build a Custom build activity.