Search code examples
visual-studio-2013tfstfsbuildrelease-management

TFS Team Build - Testing to Production


I have scoured the internet to find out what I can on this, but have come away short. I need to know two things.

Firstly, is there a best practice for how TFS & Team Build should be used in a Development > Test > Production environment? I currently have my local VS get the latest files. Then I work on them & check them in. This creates a build that then pushes the published files into a location on the test server which IIS references. This creates my test environment. I wonder then what is the best practice for deploying this to a Live environment once testing is complete?

Secondly, off the back of the previous - my web application is connected to a database. So, the test version will point to a test database. But when this is then tested and put live, I will need that process to also make sure that any data connections are changed to the live database.

I am pretty much doing all this from scratch and am learning as I go along.


Solution

  • I'd suggest you to look at Microsoft Release Management since it's the tool that can help you to do exactly the things you mentioned. It can also be integrated with TFS.

    In general, release management is:

    the process of managing, planning, scheduling and controlling a software build through different stages and environments; including testing and deploying software releases.

    Specifically, the tool that Microsoft offers would enable you to automate the release process, from development to production, keeping track of what and how everything is done when a particular stage is reached.

    There's an MSDN article, Automate deployments with Release Management, that gives a good overview: RM overview

    Basically, for each release path, you can define your own stages, each one made of a workflow (the so-called deployment sequence) containing the activities you want to perform using pre-defined machines from a pool. It's possible to insert manual interventions/approvals if necessary, and the whole thing can be triggered automatically once your build is done.

    Since you are pretty much in control of the actions performed on each machine in each stage (through the use of built-in or custom actions/components) it is also certainly possible to change configuration files, for example to test different scenarios, etc..

    Another image to give you and idea of how it can be done:

    RM deployment sequence overview