DTAP Deployment using VSO

Introduction

My previous article on this subject: Deploying a web application in Microsoft Azure.

Most projects are not created / compiled in 1 environment. We typically separate the development environment from the production environment to make sure that our development code doesn't interfere with our production code. The production environment is what is running for your clients, so it should be shielded from developer's errors.

One solution is to keep different versions of your source code. Of course, there is always the version on your development machine. In some projects, this is the only existing version... And you'd be surprised that in many of the big companies that I worked for, this was also the case. Sometimes, code is backed up to a file server (typically in a ZIP-file like "MySources.20150315.zip"), which would give *some* version control, but it lacks functionality such as deltas, easy merging, ...

A better solution is to use a Source Code Control System, such as Git, Subversion of Microsoft Team Foundation Server (TFS). In this article, we'll use TFS online, which is currently disguised as Visual Studio Online (VSO). If you don't know what I'm talking about, then please refer to my previous article on this subject: Deploying a web application in Microsoft Azure. This article also explains how to set up your team project in VSO, which is what we will build on in this article.

If you know what DTAP stands for, you can skip the following sections and go immediately to "How do we ..."

What Does DTAP Stand For?

We want to make sure that our source code is safe at all times, that changes can be applied in a controlled way and that we can work as a team. This sounds like a commercial for Microsoft TFS :-)

For all these purposes, we'll use VSO because:

• it is free for up to 5 users, and after that, the prices remain very reasonable.
• it is hosted in the cloud, which guarantees that your source code is stored well, and backed up automatically for you.
• it will also allow you to automatically build and test your code, and deploy it automatically if you wish so.

DTAP stands for Development - Test - Acceptance - Production. It is one of the ways to make your code evolve safely to production code. Let's see in more detail what DTAP stands for.

D(evelopment)

You typically start a project on your development PC, where you'll prepare for a first (incomplete) version. When the code is checked in, you'll continue working and testing locally and checking in your code from time to time. Typically, you'll want to check in your code whenever you complete a feature. Of if you write bugs (which we of course never do), you check in the code after you fixed a bug.

Now we're at the "it works on my machine" stage.

T(est)

Most developers (including me) will refrain from storing this version already in source control just because it isn't finished yet. But this is a wrong reflex: once you have *something* already, you want that code to be safe. And probably, there will be other members in your team who want to work on the project as well. This is why we create the TEST branch in our TFS. This is the branch where we'll store our code. Depending on the team that you're working in, there may be some rules such as:

• Code must compile before it can be checked in. This is the strict minimum. You don't want to be the guy that other team members will course after they get the latest changes in the project.
• Test must run successfully. In some environments, this condition is relaxed. During the automatic builds on the TFS, the test will be run after the build and this will output the results for the tests. But again, you don't want to be that guy who broke the build, or whose code made the tests fail.

When you're working in a team, other people will change the code as well while you are working at your part. So it is a good idea before you check in your code to FIRST get the latest changes and build / test your solution again. This will make sure that you don't break the build because of incompatibilities in your code. You don't want to be THE guy who broke the build / tests!

Remember: If it isn't in source control, it doesn't exist.

A(cceptance)

When you (and your testers) are happy with the code in the TEST environment, you can merge the changes with the ACCEPTANCE (ACC) branch in TFS. You can make the TFS build also deploy the code automatically to an ACC server so that your users can verify what you have done. If changes need to be applied, you should first do them on your development PC (D), move them to the TEST branch, where they'll be automatically built and tested, and when all is well, merge them back into the ACC branch.

Typically in ACC, you're not going to test the functionality anymore, because you have done that already in TEST. You now want to focus on higher loads, what happens with higher volumes of data, etc. So this is where your performance and load testing will be going on. A way to ensure to have realistic data is copying the PROD database(s) to the ACC environment and testing on those. This is fine if you don't store sensitive data. Otherwise, you may meet some privacy problems.

P(roduction)

When your users are happy (so the acceptance tests were OK), you'll do the same exercise from ACC to PROD. From that point, you'll have (updated) code in the PROD branch that needs to be deployed. Refer to Deploying a web application in Microsoft Azure for guidelines on how this can be done in a staged release environment.

The move to PROD is always a bit awkward, because you're always taking some risk here. So it is good to have this automated as much as possible, so at least human errors are excluded from the process. This is also another reason to have an ACC environment. This is where you test your deployment process as well, so you'll have a much better chance of doing it right in PROD.

To err is human, but to completely mess things up requires a computer.

How Do We Implement DTAP in Vso?

Begin Situation

Let's say that you already created your Team Project, and stored your first version of the code in it (as explained in Deploying a web application in Microsoft Azure) and move on from here.

This is the Test branch (or main branch, trunk, ...). All developers in the team have all access to this branch.

Creating the ACC Branch

Select the SampleApp/SampleApp project (in the image this is below the BuildProcessTemplates), then click on the branch icon.

In the "Branch" dialog that pops up, change the target to have an "acceptance" suffix and click OK.

In the "Map" dialog, specify where this branch will reside on your development PC.

Clicking the "Map" button will create your acceptance branch. The DEV branch is automatically copied, so at this point, both branches have the same contents.

Creating the PROD branch goes in just the same way.

Promoting Your Changes to ACC / PROD

As we saw before you make some changes on your development PC, compile, test until everything is working fine. You then get the latest version from VSO, so you have the changes from the team and you test again. If all is OK, you can move your changes to DEV (a simple check in of your code), have it built and tested again in the DEV environment (typically with nightly builds, or continuous integration) and then you want to promote the stable version to ACC.

Go to "Source Control Explorer" (View -> Team Explorer) and select the SampleApp DEV branch.

1. To get all your team's changes, get the latest version first: right click on the SampleApp folder -> Get Latest Version
2. Build and test your application locally again, if something goes wrong, then fix the problem and go back to 1, until all goes well. (I know, Goto is forbidden ;-) )
3. Check in your changes: right click on the SampleApp folder -> Check in pending changes -> Enter a comment and click on "Check In". Now your changed code is in the DEV branch (so it exists!)
4. VSO will build your code again, and run its unit tests again. It will depend on your setup when this happens (on demand, scheduled, continuous integration). If something goes wrong, go back to 1. After this loop, if finished, we have stable code in the DEV branch.
5. In the "Source Control Explorer" view, merge the changes from the DEV branch to the ACC branch. Right click on the SampleApp folder -> Branching and Merging -> Merge. Select the correct source and target branches as in the following dialog box:

   

   Click next, then Finish.

6. The merged code is not yet checked in to ACC, so check the ACC branch in.
7. As in step 4, VSO will now build and test your code again. If all is well, your users are now ready for the acceptance testing, and you can perform all the load testing, performance testing, integration testing and whatever other tests you like to do before deciding that your code is ready to be moved to PROD.

When you merge your ACC branch with the PROD branch, you can make VSO compile and deploy this new version to a staging server, then when all runs well on the staging server, you can VIP swap with the current PROD server and your users can start working with the new version. This is described in my previous article on this.

Points of Interest

Actually implementing DTAP is not a technical challenge. The real challenge is to organize your code AND your team to follow this flow. Exceptions should not be allowed, unless something is on fire. Using VSO, we can make changes directly in the code in TFS, but these changes must be retrofitted to the DEV / ACC / TEST environments as soon as possible, otherwise you'll lose your emergency change with the next merge.

For some projects, this will be overhead, but if you can't afford downtime for your website, if you don't want to ship your code multiple times because of stupid bugs, ... or if your project has any complexity, it is a good idea to put some "protocol" in the project.

History

• This is the initial version of this article.