Containers support the timely delivery of a quality software application. However, the change to a DevOps process involving containers will require testers to adapt to this new, more agile environment. What does that mean for testers and the work they do? Here's how testers can embrace these changes, containers, and DevOps.
Google Trends shows that searches for “DevOps” have more than doubled over the past twelve months. Many leading software organizations, including Google and Facebook, have built their own tools to assist in scaling development and operations, collaboration, and automation to achieve almost continuous deployment of code. Some of them are giving their tools away as open source. Others are still figuring out DevOps and how it will impact the way they code, test, and deploy software.
For teams just starting with DevOps, the wealth of information can be both empowering … and a little intimidating. Of those topics, one of the most popular is containers and their effect on building and deploying software.
Containers have been around in some form or another since the 1980s, but the open source tool Docker, combined with free and easy Linux tools (such as Jenkins, Chef, and Puppet) and cloud services, recently have made adopting containers quick, easy, and even cheap.
But What Are Containers, and How Do We Use Them?
For our purposes, a container is a virtual machine that runs on the same operating system as your computer. Instead of copying a new operating system, Docker can reuse large portions of it and “hook into” the task-switching parts, as well as share dependencies across each application’s container:
What Does That Mean for Testing?
We used to have a tool like Jenkins to create a build. The first thing we did as testers was pull that build down, install it, and use our modified servers as a “test.” With containers, we save the entire machine that will run in production, flip it on, and run it. This means the testing environment will be identical to the production environment, and you’ll even be able to run multiple builds on your machine at the same time.
Setting up a virtual machine now takes only a minute; there’s no more fighting to get the fix for sprint 21 up on the staging server while everyone else tests sprint 22. Have a problem in production? Put it in Docker, pull it down, and reproduce it locally. The number of production errors you find but are unable to reproduce in a test environment will go down dramatically.
Containers have the ability to support the timely delivery of a quality software application. However, the change to a DevOps process involving containers will require testers to adapt to this new, more agile environment.