We're using TFS to follow a pretty standard agile build process:
Nightly builds from latest source code
Build to staging server every 2 weeks
Build to production server every 4 weeks
I've got 1 and 2 set up in TFS and working great. However, I'm struggling a little with #3. If I just set up a "normal" build, it will pull the most recent source code and use that to push to the production server. But what I really want is to move the code from step #2 to the production server since it's already been vetted by the QA team.
I thought about doing a custom build template that uses XCopy or something along those lines, but then the issue is how to update the configuration strings.
I was following this article, which seems to be exaclty what I want, http://www.asp.net/web-forms/tutorials/deployment/configuring-team-foundation-server-for-web-deployment/deploying-a-specific-build, but it is not working.
How do you all accomplish this?
So this is a slightly easier way to achieve 3. if you have achieved 2.
Let your production build definition stay as it is. However to compile the same changeset that was used to compile your staging build in step 2 (which has now been vetted by QA), when you queue a prod build then on the parameters tab expand the Advanced section and find the "Get Version" property as shown below.
In here you can specify the same TFS changeset that was used to build your build in step 2. Assuming this changeset is number 84, you would write (exactly)
C84
if you compile labels then for a label named - "For build xyz" you specify
LFor build xyz
Note that "C" and "L" above are intentional.
Hope this helps.
We have a different branch for production and code only gets merged into the production branch after passing Q&A.
That allows us to apply hot-fixes to production code with changes directly on the production branch (those will eventually get reverse integrated into main then dev) while development continues on the development branches.
Once code in the development branches are ready for Q&A, it is merged into the Main trunk.
CI and nightly builds are done on the development branches - the difference being nightly builds having more comprehensive automated tests
Related
Our plan is to use Team Foundation Build service to do automatic builds, then use the testing facility to automatically perform testing on the build server then release that build onto the application server.
So far we have
Team Foundation Server with TF Build Controller configured
Build server with win2012, Visual Studio 2013 and Build agent configured.
SQL Server with SQL 2013 installed
Application Server with Win2012 and .netframework installed
My question is what do I need to do to set up automatic builds, and to execute the unit test harness once compilation is successful.
Also the deployment target machine will initially be DEV, however we would like to quickly build for test env and prod etc.
This is what I got so far.
Build Controller (Already set up I believe)
Build Agent (Already installed on build server)
Build Process Template (Do I need to do anything with this. Is this what controls the whole lot)
Team Build Definition (I had a look at this, and it seems to use the build process template)
Drop Folder (I am assuming this is where the executables will be dropped into).
At the moment I have bits and pieces of info, what I would like to know is how this whole thing is hanging together. From the moment the developer wants to do the build to the moment that exe is placed into the DEVAPPSERV (Development application server).
Is anyone able to point me in the right direction or give a summary of what I need to make this happen?
Many thanks,
Dalibor
Install TFS Server (TFS Disk) Create a Team Project Collection and any desired Projects
Install TFS Controller + Agents onto a dedicated machine (TFS Disk) Configure only the build options if on a different machine to the TFS Server
Configure Build Controller to connect to a Specific Team Collection on your TFS Server
Install VS Premium or higher on build machine, if you want code coverage results for your tests
Add some code to TFS Source Control
Create a Build Definition using the default template.
Configure the build definition.
Set the working folder for the build, include only what you need as this will speed up the process
Point the definition to your .sln or proj file.
Ensure testing is enabled and that your test assembly names will match the regex used to identify test dll's i.e. name your test assemblies with the word test.
Set the trigger to be CI or what ever flavour of build you require i.e. gated build
Save the build definition
Trigger a manual build and debug any issues
you should have the basics done and a repeatable build created.
That should cover the basics, you may want to customise the build template (see Ewald Hoffman's guide for tips), you may want to narrow down your code coverage (look for runsettings file info).
If you follow these steps you should be able to get a basic build created and running from these, if you hit any issues you can come back and ask specific questions about a particular area
In order to do automatic builds you should check the CI build option ( under the trigger build option ) and third party automated testing can be run by executed by a post build script.
See the following TFS article about post build scripts.
http://msdn.microsoft.com/en-us/library/dn376353.aspx
We are using TFS2010 for source control and TeamCity 8.x for CI. In our project we have Main branch for releases and bug-fixes and Dev for most of the development. Build steps for both branches are identical. and we have a few build configurations to go through:
I can't seem to make TeamCity to do checkout on a single branch and run build only on the branch that was checked-in to.
First attempt: I've added a VCS Root to point to $/Root that contains both Main and Dev branches and created checkout rules:
First checkin to Main works fine. Checkin to Dev after fails like this:
where DoNotExportAttribute is the file that was modified in the Dev branch. Even if I have
checkbox against "Clean all files in the checkout directory before the build".
My second attempt was to add both of the branches as VCS roots:
But this caused checkout of both branches into the same directory and whatever was checkout first was overwritten by second branch.
Is there a remedy for our case without creating separate configurations for every branch? (we started from config-per-branch, but that proven to be maintenance heavy for the number of steps we do in build)
If I understand correctly, you're trying to use a single TeamCity project for both your main and your branch builds. I would not recommend doing that. By re-using the same project for both your main and your branch builds, you will be sharing version numbers between two different beasts. Version 1.1.4 of the build might be a main build while version 1.1.5 might be a branch build.
By looking at the artifacts created by the build, it will also be difficult to identify which source code was the one selected and included into that artifact. Is the executable a main or a branch executable?
The way we solved the main vs branch problem was by creating a "template" project which contains all our build configurations (each one set up as a Build Configuration Template so they can all be changed in a single location) for building our software. Both the main line and the branch projects are created by copying this "template" project and setting the VCS root to the appropriate directory location.
We run five build agents and each build takes a fair amount of time. Having individual projects for each branch allows us to run builds in parallel if the main and any of the branches happen to have been modified at the same time whereas with one single project, the builds would be done serially.
Hope this helps.
Currently we have a build process as follows:
I do a build into our dev staging environment.
I label this in TFS.
I use SVN bridge to check out that changeset that was labelled.*
If testing for dev staging passes, I use the working copy I checked out to do another build into the next environment.
I don't want to have to use SVN Bridge to have a copy of my code somewhere else for code at a specific version, but I have not found a way to do this natively in TFS (2010).
Is there a way of doing this (point 3 and 4) using TFS, instead of SVN Bridge?
I may be completely misunderstanding what you're trying to do, but it sounds like you need to create a separate workspace, and get the code that was labeled in step 2 into the new workspace.
I have build scripts that builds, test, version and packages my projects as artifacts to a staging area for each of our environments ready for a versioned release to a given environment (and labels the changeset).
I want to stop doing this automatically and only deploy on demand.
My problem is I am using TFS and the friction is just immense.
I basically want to have an easy way to
Get a specific version from source control
build it for a specific enviroment -DONE
deploy it. -DONE
The last 2 steps are trival. The "getting by label" it not that much fun with TFS.
Any ideas/pointers other than use stop using TFS?
just ask on twitter next time :-)
Seriously though, have a look at TFS Deployer on codeplex. The way it works is that you do a normal build with versioning of the output like you normally would, but you pull out all the deployment stuff from it.
Next, setup TFS Deployer - it listens for changes in the Build Quality and the fires off a powershell script that you write that does all the deployment work. For example, when you change the quality of a build to something like "deploy to UAT" it can fire off a powershell script that then does whatever you need it to. To do a deploy you just go to build explorer, set the quality to whatever you want and let powershell do the rest - you'll get an email of the results as well so you know if it works or fails.
Go have a look at it and if you get stuck just ping me and I'll help you out.
If you follow some of MS's recommended branching strategies you can easily end up with a project structure such as:
$PROJECT\
DEV\
MyProject
STAGE\
MyProject
PROD\
MyProject
Now let's say I have three different build definitions. One each for DEV, STAGE, and PROD. This should be common considering that the build definition will define the exact solutions to build.
If I turn on CI for each of them, STAGE will be built even though the checkin occurred in DEV...
Now my question. How can I limit the build definition to execute only when a check in occurs in either a path or a solution that is part of the build definition?
When defining the working folder configuration screen - only have it start at the root of the branch you want to build.
For example, your DEV branch would be configured so that $/TEAMPROJECT/DEV/MyProject was mapped to $(SourceDir) rather than the default mapping which would have been set to just $/TEAMROJECT.
FYI - Personally, I only have CI Builds on Dev branches and queue manual builds for a push to QA. I also normally don't do a re-build for production but just push the build binaries that were QA'd. I also keep by build configuration folder inside the branch i.e. $/TEAMPROJECT/DEV/TeamBuild rather than the default $/TEAMPROJECT/TeamBuildTypes and therefore changes to the build configuration are also pushed up through the branches. That said, you have to stick with the default if you wanted the build configuration to be visible to VS2005 clients.
Hope that helps,
Martin.