At my new project I am responsible for configuration management. We are using Visual Studio 2010 Premium and Team Foundation Server 2010 (TFS). The app we are going to build is an ASP.NET MVC Web application as the presentation layer that communicates to the data store via a services layer . The data store will be a SQL Server database. For now the service layer is not implemented, because the build is the first thing I do.

Continuous Integration
Because the app is going to be a product that is very important for the organization (core business), I am going to use Continuous Integration (CI), every check-in will result in building of the product and running all our unit-tests. CI is very easy to achieve with TFS.

Nightly Build
In addition to the unit-testing and building of the product, I want a nightly build where the build also deploys the application to a test web server, deploys the database to a separate test SQL Server and when all these tasks have succeeded run automated web tests on the web application, so the state of the application is always known and the testers will have a report with the test results first thing in the morning. I am aware of Lab Management, which makes these configuration’s easier to manage, but as I mentioned we are using VS Premium for now, so I can not leverage Lab Management at this moment in time.

To deploy a web application using Team Build I want to leverage MSDeploy. I had to install MSDeploy on the test webserver, the application will be deployed on. The installation and configuration of MSDeploy was not straightforward to say the least.

Here are some links to help with that:

Auto deploy Web application using Team Build
After MSDeploy is working on the webserver, the deployment of web applications using Team Build 2010 is a question of setting the right MSBuild arguments in the new Build settings window of the Build definition feature.

Process tab build settings build definition Team Build 2010
Process tab build settings build definition Team Build 2010

The following arguments where needed to make my configuration work, deploying via MSDeploy to another machine running IIS:


/p:DeployOnBuild=True /p:DeployTarget=MSDeployPublish /p:MSDeployPublishMethod=RemoteAgent /p:MsDeployServiceUrl="machinename webserver/msdeployagentservice" /p:DeployIisAppPath="BuildTest" /p:username="domain\Username" /p:password=P@ssword

Listing 1: MSBuild arguments

The most interesting arguments are:
MSDeployPublishMethod: InProc or RemoteAgent
MSDeployServiceUrl, because I use RemoteAgent, I could not use https://machinename:8172/msdeploy.axd (msbuild puts http before the url…), I took some time to figure out that the service listens to http://machinename/MSDEPLOYAGENTSERVICE also.

Web.config transformation
.NET Framework 4.0 comes with the web.config transformation feature, a web.config has a shadow file per build type, so a web.debug.config and a web.release.config.

<connectionstrings><add name="BuildtestConnectionString" connectionstring="Data Source=SQLMACHINE;Initial Catalog=DATABBASENAME;Integrated Security=false;uid=user;password=P@ssw0rd" providername="System.Data.SqlClient" xdt:transform="SetAttributes" xdt:locator="Match(name)" /></connectionstrings> 

Listing 2: web.config transform web.release.config

When the project is build as a release build, the values of the attributes in the connectionstring are changed to reflect the values in the connectionstring in listing 2.

This was all I needed to do to make Team Build deploy my web app to another server, I will report on how I configured Team Build to deploy the database (an vsts database project) in a follow up post.

Henry Cordes
My thoughts exactly…

On March 7th I attended some sessions at the Dutch Developer Days 2006. A session I attended was: Dynamics of Microsoft Solution Framework and Visual Studio Team System by Anko Duizer from A-Class.
He told about how he always worked with and liked MSF. He had the opportunity to see how Microsoft uses MSF in real life and told us how much he would like to share this knowledge. The reason why he wanted to talk about MSF and Team System was:

  • Software development is more than just good programming
  • Microsoft Solutions Framework is the result of many years of experience
  • Visual Studio Team System is a great enabler for the use of MSF 

There are a few methodologies that MSF supports: MSF for Agile Software development, MSF for CMMI process improvement.
Team System ofcourse is all about team development. Anko said he learnt a lot from reading a book written by Jim McCarthy called Dynamics of Software Development.
He claimed it opened his eyes and he thinks it still is a book that everybody in software development should read.
A few rules from this book where highlighted, because they are real important. In the book there should be much more. The rules I saw made sense and I think I will pick up this book one of these days. I must say Anko had a software problem, so I think a lot of the demonstation he had planned could not be shown, which in my opinoion was a shame. So I will  write down some rules from which I think they make sense (although some are really obvious):

  • Establish a shared vision (Make everybody aware of what they are doing and why)
  • Create a multi-release technology plan (Make  plans for the future, if you can not get features in this release, you can get them in future ones)
  • Don’t flip the bozo bit (Every department has got one, an employee from who nobody really knows what he is doing, we do'nt want 'bozo's' on our team, or become one)
  • Use feature teams (Use teams for small parts of an application)
  • Use program managers (but it is important to make the distinction that he is servant not master! He supports the team, not tells what to do)
  • Design time at design time
  • Remember the triangle: Features, Resources, Time (You can not get features, if you have not got the time and/or resources)
  • Don’t know what you don’t know (If you can not know something, aknowledge this)
  • Don't go dark (Don't let people get away with doing things without anybody specifically knowing what they do)
  • If you build it, it will ship (Make sure code will built!)
  • Get to a known state and stay there (It is better to release something, than trying to built new features that are late)
  • Don’t trade a bad date for an equally bad date (If you do not make a deadline, don't say we release a week later, but will include the new feature you need!)
  • Triage ruthlessly (Like the war movies, only in software development)

Henry Cordes
My thoughts exactly...

TFSC or Team Foundation Source Control is built from ground up, Microsoft did not update Visual SourceSafe and call it TFSC. It is a multitiered architecture.
On the other hand, if your familiar with Visual SourceSafe, the look and feel is basically the same, there are just more features.
There are some new features in TFSC compared to Visual SourceSafe, there are:
  • Changesets
  • Branching
  • Merging
  • Shelving
TFSC introduces a concept called changeset. With Visual SourceSafe and other source control products, the files under source control had no linkage, they all where individual files.
Changesets describe a group of associated file modifications, each changeset is given a unique identifier for tracking and reporting.

Branching in TFSC is intelligently copying items from one project to another. The origin, context and history is maintained and future changes can be merged back into the original path. This allows multiple builds and releases to be maintained efficiently. Another benefit of branching is storage space efficiency. The source control server minimizes the required storage by maintaining one copy of the content.

Merging (in CVS this process exists for a long time already) reconciles all the changes from branched code (“the source”) with the original code (“the target”). This is more than blending text, it will merge additions, deletions, undeletions and renames from the source to the target.

Multiple checkout
Team System projects can be configured for multiple checkout . this feature allows more than one user to edit the same file simultaneously. The same engine that merges changes from branched projects merges changes from two or more checked out projects back to the source (people working with CVS know this feature is nothing to be afraid of).

Shelving is another new key concept to TFSC. Shelving allows a developer to store pending changes to the server without checking them in (in the form of a shelveset).
A shelveset is similar to a changeset, except the files are stored on personal space on the server.
Reasons for shelving:
  • Switching to another project with higher priority;
  • Code fails a check in policy and can’t be fixed immediately;
  • Code is not complete enough to be shared
  • Developer needs to leave and wants to keep his code safe

Visual SourceSafe
SourceSafe continues to be available, it will have some new features also:
HTTP access through a Web Service interface
Copy, modify, merge model
A LAN performance booster
Asynchronous file opening, start working before loading is complete
Better support for projects in multiple timezones and multiple languages and Unicode

Henry Cordes
My thoughts exactly...