​​​TFS and Windows Azure work wonderfully together. It only takes a minute to configure continuous deployment from Visual Studio Online (visualstudio.com) to a Windows Azure Web Site or Cloud Service.

This is by far the most simple method to achieve continuous deployment of your websites to Azure.

But, if your application is more complicated, or you need to run UI tests as part of your deployment, you should be using Octopus Deploy instead according to the Do you use the best deployment tool​ rule.​

Figure: Setting up deployment from source control is simple from within the Azure portal

Figure: Deployment is available from a number of different source control repositories

Suggestion to Microsoft: We hope this functionality comes to on-premise TFS and IIS configurations in the next version.

Often, deployment is either done manually or as part of the build process. But deployment is a completely different step in your lifecycle. It's important that deployment is automated, but done separately from the build process.

There are two main reasons you should separate your deployment from your build process:

You're not dependent on your servers for your build to succeed. Similarly, if you need to change deployment locations, or add or remove servers, you don't have to edit your build definition and risk breaking your build.

You want to make sure you're deploying the *same* (tested) build of your software to each environment. If your deployment step is part of your build step, you may be rebuilding each time you deploy to a new environment.

Octopus Deploy allows you to package your projects in Nuget packages, publish them to the Octopus server, and deploy the package to your configured environments. Advanced users can also perform other tasks as part of a deployment like running integration and smoke tests, or notifying third-party services of a successful deployment.

Version 2.6 of Octopus Deploy introduced the ability to create a new release and trigger a deployment when a new package is pushed to the Octopus server. Combined with Octopack, this makes continuous integration very easy from Team Foundation Server.

What if you need to sync files manually?

Then you should use an FTP client, which allows you to update files you have changed. FTP Sync and Beyond Compare are recommended as they compare all the files on the web server to a directory on a local machine, including date updated, file size and report which file is newer and what files will be overridden by uploading or downloading. you should only make changes on the local machine, so we can always upload files from the local machine to the web server.

This process allows you to keep a local copy of your live website on your machine - a great backup as a side effect.

Whenever you make changes on the website, as soon as they are approved they will be uploaded. You should tick the box that says "sync sub-folders", but when you click sync be careful to check any files that may be marked for a reverse sync. You should reverse the direction on these files. For most general editing tasks, changes should be uploaded as soon as they are done. Don't leave it until the end of the day. You won't be able to remember what pages you've changed. And when you upload a file, you should sync EVERY file in that directory. It's highly likely that un-synced files have been changed by someone, and forgotten to be uploaded. And make sure that deleted folders in the local server are deleted in the remote server.

If you are working on some files that you do not want to sync then put a _DoNotSyncFilesInThisFolder_XX.txt file in the folder. (Replace XX with your initials.) So if you see files that are to be synced (and you don't see this file) then find out who did it and tell them to sync. The reason you have this TXT file is so that people don't keep telling the web

NOTE: Immediately before deployment of an ASP.NET application with FTP Sync, you should ensure that the application compiles - otherwise it will not work correctly on the destination server (even though it still works on the development server).

Octopus Deploy 2.6 introduced a new Lifecycles feature that makes Continuous Integration from TFS much easier. It's a must have for projects in TFS that use Octopus for deployment.

As well as allowing continuous integration, the Lifecycles feature adds some good governance around when a project can be deployed to each environment.

Lifecycles can be found in the Library section of Octopus Deploy. By default, a project will use the Default Lifecycle which allows any deployment at any time.

Figure: Lifecycles can be found in the Library

You should create a new Lifecycle for each project you've configured with Octopus Deploy. You should set up a phase to continuously deploy to your first environment (e.g. test or staging), but make sure the final phase of the lifecycle is a manual step to production.

Figure: Good Example - This lifecycle has two phases: an automatic release to a Staging server, and a manual release to the Production server.

In the Process tab of your project definition, there's a panel on the right-hand side that lets you configure the Lifecycle to use. You should also enable Automatic Release Creation. If you have a CI build which publishes a new package to the Octopus NuGet feed as part of your build using OctoPack, and your first Lifecycle phase is automatic, this will result in continuous deployment to your CI environment.

Figure: Good Example - This combination results in Continuous Deployment to the Staging server when a new package is pushed

​Publishing from Visual Studio is a convenient way to deploy a web application, but it relies on a single developer’s machine which can lead to problems. Deploying to production should be easily repeatable, and able to be performed from different machines.

Figure: Enter the DeployOnBuild MsBuild argument, and then enter the name of the deployment batch file you wish to execute upon successful build of the project.
Every time this build is executed successful (and all the unit tests pass), the specified batch file will run – deploying the site automatically.

In the image aboce,​ Vm-SynWeb.Deploy.Bat is a batch file that will deploy your web site to Vm-SynWeb Vm-SynWeb.SetParameters.xml is a Web Deploy SetParameters file that specifies environment specific settings. _Deploy.Bat is the base batch file that your environment specific deployment batch files will call.

Figure: It is important that each of the batch and parameters files has it ‘Copy to Output Directory’ setting set to ‘Copy Always’

​​(Before you configure continuous deployment) You need to ensure that the code that you have on the server compiles. A successful CI build without deployment lets you know the solution will compile.

Figure: The Build definition name should include the project name. The reason for this is that builds for all solutions are placed in the same folder, and including the build name makes the Build Drop folder organised

Figure: On the Trigger tab choose Continuous Integration. This ensures that each check-in results in a build

Figure: On the Workspace tab you need to include all source control folders that are required for the build

Figure: Good Example - The SetParameters file specifies MS Deploy parameterisation values. Most important is the target “IIS Web Application Name” on the target serverSee
Vishal’s blog for more details.

​In theory WebDeploy can create a site for you when you deploy. The issue with this is that many settings are assumed.

Always create the site before deploying to it, so that you can specify the exactly the settings that you desire. E.g. the directory where you want the files for the site to be saved, the app pool to use and the version of .Net.

Ideally, Builds are created once, and can then be deployed to any environment, at any point in time (Build Once, Deploy Many).We do this by including deployment batch files in the solution, and specifying them to be called in the Build Process Template.

​

Figure: Good Example - Include deployment scripts in the solution, and execute them from the Build Process Template

Bad Example - Using Builds to Deploy

Good Example - Using Batch File

Deployment Overview

A separate build is created per target environment

The MS Deploy parameters are put into the MSBuild parameters setting on the process template

The build for the shared development server is set to be a CI build so it is executed on every check-in

One batch file per target environment is created and checked into source control alongside the web project

Help and improve these rules

Nothing great is easy. The SSW rules are a great resource for developers all around the world.
However it’s hard to keep rules current and correct. If you spot a rule that is out of date, please email or if you are cool tweet me.