Docker in the Quality Assurance Phase
Docker can be used to create immutable servers, which are software systems that are dedicated to one purpose and are never changed once they are released from development. Updating or changing anything about an immutable server means replacing the server completely.
Testing immutable servers is much less complicated with Docker because there is nothing for the QA department to tweak on its own. The instructions for setting up and running the new software is embedded in the system; just run the docker command and test. If the software breaks, send it back to the development team, who can quickly recreate the bug.
Beyond just hunting bugs, it is easy to set up a container that runs a previous version of software, and one that runs the most current version, and to test them on the same machine. Turnaround time for activities like debugging, testing, and A/B testing is minimized.
Docker in the Production Phase
The advantage of immutable servers is that there is nothing to configure, change, and possibly break, because every component is hard-coded into the system. The disadvantage of immutable servers is that if these systems have to be deployed on individual boxes, or even on VMs, the cost and overhead of updates and changes can become onerous.
Using Docker means that an immutable server is just another process running on a box. There is no cost in taking down a container and substituting another, and the only time costs increase is when another physical box, or VM, needs to be added to provide more space for Docker containers. In production, it becomes easy to do things like blue-green deployment, where the existing production network (by default, this is blue), is slowly replaced by new software or a new network (green). As the transition occurs, the production administrators can monitor performance, faults, and hopefully decrease customer complaints. If any indicator signals trouble with the new software, blue floods back into the green areas. Docker allows this to happen quickly because the time required to read a Docker image and start a Docker container is at most seconds, versus the minutes and even tens of minutes required to start a new VM or physical machine.