The last time I took a look at Microsoft’s Web Deploy, it was still called the “IIS Web Deployment Tool” and at the time, it was little more than a dream of how automated web application deployments for IIS should be done.
The tool was still in its conceptual/beta phase and it lacked a significant set of features which I needed at the time (as in - yesterday), so in order to accomplish my goals of reducing deployment friction between developers/testers/ops, I went on to creating my own sort of Web Deploy toolkit.
The system was built on two core applications, a command line tool and a web application.
The command line tool (Deployment Console) would take a variety of parameters such as the source “package” (zip file) to deploy from, the target server and target directory for the deployment, FTP info for transferring files, IIS info, etc. Simply enough, Deployment Console really had only two jobs. The first, to FTP the source package to the target server for deployment. The second, to take the incoming deployment parameters and dispatch a web request to the target deployment server.
Deployment Agent (the web application responsible for the actual deployment process) would be hosted on the target server and would listen for incoming deployment requests. Once received, deployment agent would spin into action, pause the target website, clean out existing files, unpack the package, etc.
I set up Deployment Agent’s on my INTEGRATION, QA and STAGING environments and hooked Deployment Console into my Continuous Integration build/deployment pipeline allowing for
- Automated deployments to the INTEGRATION environment upon successful developer/tester check-ins (successful = compiles + passes all non-functional requirements/fxcop warnings/code coverage metrics/etc + passes unit tests)
- Push-Button automated deployments to the QA environment, triggered whenever the QA team felt comfortable consuming a new build
- Push-Button automated deployments to the STAGING environment, trigged whenever the QA/Performance/Operations team felt comfortable consuming a new build
Now, as I review the latest version of Web Deploy (2.1), I see that Microsoft has really put a lot of effort into making deployment a first class member of the software development process. Where the “IIS Web Deployment Tool” was a step in the right direction, Web Deploy is few miles down the road to deployment bliss!
Architecturally similar in many aspects to my own deployment toolkit, Web Deploy consists of a command line tool (MSDeploy.exe) and a Windows Service (msdepsvc - an “Agent” accessible by HTTP).
In addition, Microsoft has integrated Web Deploy with Visual Studio, IIS and SQL Server allowing you to not only package (zip) your application code, but the database changes and server configuration settings which power it! With a simple command line execution of MSDeploy, you can easily create a deployment package with your application code, IIS server settings and even your database migration scripts (support is still spotty here, but you can always dream!).
From within the IIS 7 management console, you can specify one of these packages for deployment. IIS understands the concept of a package, allows you to view its content, customize deployment parameters and execute the entire deployment process.
Web Deploy is not perfect and while Microsoft has made some significant strides forward in the area’s of automated application/configuration/database deployments, there are still a few kinks to be worked. That said, its got integration into the primary tools of the trade (IIS, Visual Studio, etc) and will only get better over time.
On that note, I think its time I stop committing to Deployment Console and Deployment Agent and focus on migrating the deployment steps of my build/deploy pipeline over to Web Deploy.