Often on projects nowadays, having an automated build and deployment process is a must. Depending on the maturity of the environment there are actually a lot of different ways to achieve these goals, but this post is about one of the simplest ways to get going using a minimum amount of brittle batch/command line tools. For the purpose of this article, I’m assuming you want to use MS Deploy to deploy a web application to in house environments.
Ingredients (what you need):
- TFS and Team Build
- Web Deploy Installed on Target Servers
- Comfort with a little XML editing.
Step 1: Install Web Deploy on Server
Using MS Deploy is extremely convenient – you can package up a website and send it to a server and have it installed with dependencies with minimal effort. Before following this post, you’ll want to install Web Deploy on the target servers.
Step 2: Ensure you have the proper “Configurations” to deploy with
Using Solution/Project Configurations. Typically when you create a new project/solution, you get two configurations: Debug and Release. If you’re using Team Build to perform the deployment, it can be helpful to create a configuration per environment: Dev, Test, QA, Production, etc. To do this, right click on the solution and select “Configuration Manager…” Then select <New> in the Active Solution Configuration. It will prompt you for a name and if you want to copy settings from an existing configuration (such as Debug / Release). Pick one of those.
Step 3: Edit your project file manually
Then you need to modify your csproj (or vbproj) file. Normally you’d expect to use the UI to make project property changes, but in this case, these properties have not been given places in the Visual Studio UI yet. Notice how the project file starts out with <PropertyGroup>s – one that is global, and several (one for each configuration). Find the first one in the file and add these lines of XML in the middle.
These settings will be set for all configurations, even “Debug” which is usually the configuration you use for local development. But because the “DeployOnBuild” property is set to false, msbuild doesn’t do anything with these values.
Next it’s time to modify the configuration that you plan to use for deployment. Look in that file, and you’ll find a line like the following: <PropertyGroup Condition=“ ‘$(Configuration)|$(Platform)’ == ‘Dev|AnyCPU’ “>
assuming “Dev” was the configuration you want to deploy with.
Now, we just need to add two lines inside of that PropertyGroup:
DeploymentIisAppPath – this the “Web Site” name and virtual directoy path that exists within your IIS Server. Do not confuse this with physical file system path.
MsDeployServiceUrl – this is the name of the server – which is all you need in this case, MSDeploy automatically uses the default port of 1872 with SSL to connect and deploy this application.
Step 4: Modify your Team Build Definition
Edit the build definition, go to the “Process” tab. Find “3. Advanced” and you’ll find a place to specify “MSBuild Arguments” – just add the following on that line:
This approach is useful only when you need/can deploy and build on the same action. Some environments require build and deployment to be separate actions such that the compiled bits are identical between environments. This solution does not achieve that – you technically should have a build definition per environment in this case. It has the benefit of being very declarative, plays nice with web config transforms, and overall very easy to implement. Lab Management – a feature of VS/TFS is another way to achieve this – when virtualization can be used – and is relatively easy to set up in 2012.