Usually when people think of code, they envision programs executed by computers to do X, Y, or Z. Infrastructure as code (IaC) is different. It is a method you can use to define a configuration model that represents a piece of your server environment.
For example, you can use IaC to define a web or database server. Or you can use it to define a series of patch updates to a set of servers. With IaC, you treat the work of changing or updating infrastructure just as you would a code change: You track the configuration file in the revision control system, where you review it, test it, and put automation in place.
There are many advantages to implementing IaC, just as there are advantages to using a mature software development methodology. Using IaC configuration files and properly tracking them through a revision control system has four key benefits:
- You can revert to a previous known-good state.
- Changes are stored centrally and are available to other users.
- There's rapid duplication of infrastructure.
- You can eliminate configuration drift between environments.
With IaC, users can treat provisioning and updating like an agile development cycle. With this mindset, they can more easily manage small changes that are tested and quickly released. And their focus can be on automated testing of changes before deploying to production.
Here's how your quality assurance (QA) team can achieve awesomeness with better automation.
First steps: Some prerequisites
Sounds cool, right? But before you get started, there are a few prerequisites you'll need to get out of the way.
- You need a dynamic infrastructure that can support IaC.
- You'll need to approach IaC with an understanding of the practices you need to have in place for it to succeed.
- You need a revision control system. And you need to understand the different types of IaC configuration models.
First, your infrastructure environment needs to be programmable, have resources on demand, and be set up for self-service; these are the features that define a dynamic infrastructure. With it, users can make changes to the infrastructure on their own, through an interface that they can reached by code; they don't have to wait on IT to do it for them. Dynamic infrastructure is not limited to cloud platforms; it can also be bare-metal systems with lights-out technology.
Second, to achieve automated infrastructure deployment for IaC, you need a change of mindset. One of the great benefits of IaC is the ability to make small changes fast and respond to needs quickly. Gone are the days of having end users endure server downtime while major upgrades occur.
Now you push multiple, small changes out whenever needed in an automated manner so that updates are seamless in the environment and invisible to the end user. Finally, your revision control system (RCS) is an integral part of IaC. Users should commit IaC files to the system, check them for updates, and then check them back in once they have completed any updates.
[ Special Coverage: STARWEST Conference 2019 ]
What about tools?
There are two primary ways to define IaC configurations, so before you look at any tools, it is important to understand the differences. The first method of defining a configuration is procedural; it defines how the environment should change. The second is declarative; it defines the resulting environment.
In addition, most tools include orchestration and/or configuration management features. Orchestration tools focus on provisioning servers and other resources, while configuration management tools manage software on existing infrastructure.
Tools? Check. Now what?
Assuming that you have a dynamic infrastructure and RCS in place and have chosen an IaC tool that best fits with your infrastructure and uses, you're ready for the next steps to implementing IaC.
First, as with any software development project, you need to plan. Then you must develop the configuration file for each discrete part of the infrastructure and capture that in the RCS.
Next build and test the infrastructure parts in a sandbox environment. Finally, you can release the IaC and use it to deploy a full ecosystem, whether to development, testing, staging, or production. Later, when you're confident, you can move to multiple instances.
Once you've modeled the infrastructure, selected an appropriate IaC tool, and begun the process of implementing IaC, make sure that work on IaC follows the same DevOps workflow as your other software products. This workflow should allow for the continuous improvement of any IaC configuration files and should use automated testing for deployment.
How infrastructure as code helps testers
There are several situations where IaC can help with testing. For example, one problem in QA environments is configuration drift, where the QA and production environments get out of sync with operating system/patch levels or other deployed software.
Having one configuration model through IaC means that changes get deployed to all environments, whether there are two environments or more.
Even with an on-premises product, you can use IaC to help with testing. Use it to standardize deployments between development and QA, or even between different testers/QA teams. If the product in question is part of a larger ecosystem, then you can use IaC to facilitate deployment of the ecosystem and automation to those systems.
You can also use IaC to facilitate the deployment of specialized systems for performance, load, or security testing. Because you create the configuration of a system only once, you can create and destroy these specialty systems as needed.
What's the catch?
Nothing is perfect, especially in software. While the benefits of IaC are many, challenges will arise. The largest is gaining an awareness of any security risks resulting from IaC.
Also, you must guard against ad-hoc updates, which will result in configuration drift and out-of-date IaC configuration files. Finally, if testing infrastructure changes using IaC is not thorough, there is the chance that you may propagate errors from one configuration file to multiple systems.
To guard against this, develop automated tests and automated verification systems. Finally, have a process in place to roll back changes to the last known good revision.
For more on how test engineers can leverage infrastructure as code, come to my talk at STARWEST 2019, which runs from September 29 to October 4, 2019, in Anaheim, California. TechBeacon readers can save $200 on registration fees by using promo code SWCM.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
