Search code examples
asp.netautomated-deploy

How do I setup this deployment process for ASP.NET?

I run a small web development shop working with ASP.NET (Webforms and MVC). We do work for a a variety of clients so there are potentially many projects active at any time (some just waiting for a maintenance update or a bug fix).

Currently we deploy in a very manual fashion (FTP files to server, remote into server, copy live site to backup folder, copy new files to live site). Obviously this leaves a lot to be desired and mistakes happen.

I've been reading a lot on CI and automated build and deploy tools but I can't quite wrap my head around it as they are all look fairly daunting to setup.

I am looking to automate this deployment process and I'm trying to work out which tool would be the best to learn and get going with:

  1. Developer checks code into Mercurial on local machine and then synchronises with master repository on network connected build server.
  2. Build server starts build and checks unit tests are good. Rinse and repeat.
  3. Developer manually selects deployment to remote windows server via FTP (is there another way?) with zip file (ideally only containing the changed files from the previous deployed version).
  4. Remote server polls folder where FTP'd files end up, unzips them, copies them to test folder, backs up the test database and runs upgrade script against test database (or using a migration app like migratordotnet or rikmigrations). Config transformations would also need to be performed.
  5. Client reviews changes and accepts them or provides feedback.
  6. If client accepts, Developer pushes "Deploy to staging" button on remote server's web interface and live database is backed up, restored to staging database, live site's file are copied to staging sites folder (effectively creating a clone of the live site), the test site's changed files are copied to the staging site (excluding certain folders such as test image uploads, etc) and the migration script is run again.
  7. Developer checks changes haven't broken staging site.
  8. Developer pushes "Deploy to live" button on remote server's web interface and live site is copied into a backup folder and staging site's file are copied into it's place (excluding user uploaded images, etc). Live database is backed up and migration script is run.
  9. If something goes wrong the developer is able to revert the live site back to the previous version by having the backup files copied back into the live site's folder and the previous database back restored.

I don't really want to have to struggle with 100's of configurable options. It must be quick to setup for a new project (no longer than 5 minutes) and repeatable.

We are not enterprise but if I have to spend some money to get this going I am full prepared to pay for licenses.

Solution

  • I am a developer for BuildMaster, a tool that basically does everything you've listed here. I'll try to touch upon a few of your bullet points as to how it could help you:

    1. BuildMaster supports Mercurial (along with several other VCSs out there) such that you can either label your code during an automated deployment and/or get labeled (or latest) code
    2. When you are creating your deployment plans in BuildMaster you can have your build "fail fast" if the unit tests do not pass
    3. BuildMaster uses either self-hosted or IIS-hosted agents that can be installed on any server you plan on building from or deploying to. BuildMaster goes one step further with regard to zipping your build outputs into built-in "build artifacts", which can then either be deployed as a whole right over the top of your existing web site or to a temporary directory and then transferred over to the web server such that only modified files are transferred - you can also exclude files/directories (e.g. sync everything except for \Uploads, \Logs, etc.)
    4. You won't need an external tool to poll directories for changed files to deploy, you would just click "Promote to Testing" in BuildMaster which would include "Backup Database" as part of your deployment plan. Databases in BuildMaster are handled such that each environment has its own "instance", and you can set up change scripts that will be guaranteed to only be run once per environment when added to your deployment plan for that environment.
    5. BuildMaster's architecture (essentially a web application with a service/database back-end that does the work) allows you expose the necessary parts of the web application to your clients where they would be able to "approve" a test build before it is promoted to the next testing environment.
    6. If your staging deployment plan includes backing up the database and copying production's files, clicking the "Deploy to Staging" button would do everything you include in the plan.
    7. Our approval system could handle this (e.g. 1 developer and 1 manager must approve the build before it goes to production)
    8. Same as #7
    9. This step can mostly be achieved with BuildMaster... there is no "restore" functionality built-in to the software. However, with the built-in artifact storage in BuildMaster, you can re-execute an older promotion to production and it would put the old zipped artifact files back in one click. For the database, it's a little trickier, you'd have to manually restore the DB.

    Typically, the installation process is a few clicks and only requires IIS with ASP.NET 2.0 installed on the web server that will host BuildMaster, with either SQL Server Express (part of the install) or your own instance of SQL Server.

    The initial setup should be fairly straightforward and there are examples you can find in the software that will create an "Application" from source code in a public SVN repo and build it.

    The other main feature you may like is the configuration file management. Since you mention ASP.NET, you can create your web.config file in BuildMaster as a template and deploy it as part of your deployment plan with different values based on your environments. This way, you'll only have to keep your development version in source control, and one template version in BuildMaster for the rest of your testing environments.

    I would recommend starting with the free trial and reading a tutorial to get a basic application up and running. If you have any questions, there is integrated help on our website and built-in to the application once you get it installed. There is so much more that cannot be added to this post that you may find useful (manual change control tracking, notifications, reports, extensibility, etc.); if you're interested you can check out the full list of features!