Some years ago, I took on the support of a WebForms app for a vehicle hire company. The app was used by a team of about 30, and it was a small-scale deployment—they had one server hosting the database and one server running the web app. Although small, it was the core application for the business, and everything they did ran from this app.

The app had a very simple architecture: just one web application and an SQL Server database. Initially, I did a lot of work to improve the performance and quality of the application. After that, it became a caretaker role, where I would manage two or three releases a year, adding new features or fixing old bugs.

These releases were always more difficult and time-consuming than they needed to be. The release usually consisted of the following:

• A Web Deploy package with the updated application
• A set of SQL scripts with schema and data changes
• A manual testing guide to verify the new features and check for regressions

The deployment was done outside office hours to give us a window of time to fix any problems we found. I would access their services using the Remote Desktop Protocol (RDP), copy the artifacts, and manually run the Web Deploy package and the SQL scripts. It was usually months between releases, so I'd rely on the documentation that I'd written to remind me of the steps. Then, I'd walk through the testing guide and check the main features. Sometimes, there were problems because I was missing an SQL script or a dependency for the web application, and I'd need to try and track down an issue I hadn't seen earlier.

Until recently, the application was running on Windows Server 2003, which has long been out of support. When the company wanted to upgrade Windows, I recommended the move to Windows Server 2016 Core and Docker. My suggestion was to use Docker to run the web application and leave SQL Server running natively on its own server, but use Docker as a distribution mechanism to deploy database upgrades.

The move to Docker was very simple. I used Image2Docker against the production server to produce an initial Dockerfile, and then I iterated on that by adding a health check and environment variables for configuration. I already had an SQL Server project in Visual Studio for the schema, so I added another Dockerfile to package the Dacpac with a deployment script for the database. It took only two days to finalize the Docker artifacts and have the new version running in a test environment. This was the architecture with Docker:

• 1: The web application runs in a Windows Docker container. In production, it connects to a separate SQL Server instance. In non-production environments, it connects to a local SQL Server instance running in a container.
• 2: The database is packaged into a Docker image based on SQL Server Express and deployed with the database schema in a Dacpac. In production, a task container is run from the image to deploy the schema to the existing database. In non-production environments, a background container is run to host the database.

Since then, deployments have been straightforward, and they always follow the same steps. We have a set of private repositories on Docker Hub, where the versioned application and database images are stored. I configure my local Docker CLI to work against their Docker Engine, and then I do the following:

1. Stop the web application container.
2. Run a container from the new database image to upgrade SQL Server.
3. Use Docker Compose to update the web application to the new image.

The biggest benefits of moving to Docker have been fast and reliable releases and reduced infrastructure requirements. The company is currently looking at replacing their current number of large servers with more smaller servers so that they can run Docker Swarm  and have zero downtime upgrades.

An additional benefit is the simplicity of the release process. Because the deployment is already tried and tested, using the same Docker images that are going to be used in production, there's no need to have someone who understands the app available to track down issues. The company's IT support folks do the releases now, and they can do that without my help.