If you still need help, visit Application Lifecycle Management and book in a consultant.
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 website 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.
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.
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.
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.
Configure the ExecuteBatchTemplate Build Process Template.
Your source control repository should be the source of all truth. Everything, always, no-matter what should go into source control.
This includes any deployment scripts and Web Deploy parameter files if you need them.
(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.
You should create a Deployment Batch file and SetParameters file for each Environment.
TODO: MattW - View GitHub issue
If you use Azure websites and VisualStudio.com you can set up continuously deployment in 5 minutes.
In theory WebDeploy can create a site for you when you deploy. The issue with this is that many settings are assumed.
You should not Install Web Deploy from the Web Platform Installer, but instead download the installation from the IIS website (http://www.iis.net/downloads/microsoft/web-deploy).
The reason for this is that the Web Platform Installer does not install all of the components required for continuous deployment, but the downloaded package does.
Update your Build to use the ExecuteBatchTemplate Build Process Template.
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.
You can use Visual Studio's Web Compiler extension to create a bundle.css and test if CSS was compiled successfully.
In the Face of Armageddon
When there's a major error during deployment or a catastrophic fault happens, what is your first instinct? Is it to hit that Roll Back button?
It feels like reverting back to the previous stable version is the safest and quickest way to restore functionality.
Figure: Fixing Problems
However, rolling back can have several negative consequences, making it crucial to consider the drawbacks:
- Negation of new features and improvements
- Cycle of constant reversion
- Resource-intensive and disruptive
- Causes downtime and requires manual intervention
From Setback to Comeback
To support making decisions, developers should set up robust monitoring systems. Effective monitoring ensures accurate and prompt issue identification, aiding informed decision-making. This is particularly important when it comes making the decision to Roll Forward.
Here are the reasons why you should Roll Forward:
- Continuous Improvement: Rolling forward allows for incremental improvements, ensuring that any issues are promptly addressed without hindering overall progress.
- Minimized Downtime: By fixing issues on the go rather than reverting to previous versions, Rolling Forward reduces system downtime and minimizes disruptions to business operations.
- Data Integrity: Changes that minimally impact user data or schema allow for seamless updates without risking data integrity. Rolling Forward ensures that data remains intact and consistent.
- Customer Confidence: Demonstrating a commitment to Rolling Forward and resolving issues promptly can build customer confidence and trust in your ability to deliver reliable and up-to-date solutions.
By prioritizing rolling forward, you embrace a proactive approach that promotes resilience, agility, and continuous delivery.
Prevention is Better Than Cure
To keep your deployments stress free, do the following:
If issues occur, rolling forward with targeted fixes is the best way to maintain progress and stability.