QA is central to DevOps transformation. If DevOps is about bridging gaps in culture between teams, then QA does this best by being the common denominator across both Dev and Ops teams.
As new technologies and features make their way into the application architecture, major changes are required at every level of the application stack. This includes code refactoring, ensuring backward compatibility of features, revisiting core design decisions from the past, and changing the service and data model.
DevOps is all about culture, and It takes a robust QA practice and a change of culture to be able to sustain a DevOps transformation. Below, I take a look at the cultural changes you can pursue in order to enable better QA.
Every DevOps transformation story begins with the realization that the current setup isn’t working. Releases are high-stress events, full of unpredictable failures, and innovation is slowed down as a result. Once you’ve decided it’s time to deal with the root of your issues, DevOps becomes the clear solution. Faster releases is the key reason organizations adopt DevOps.
Yet, releases don’t get faster by focusing on the last mile of the development pipeline. You need to consider every step across the entire product lifecycle to achieve faster releases—Only then will you have quality and reliability, which are equally important. As you push the limits on the number of new features released and the complexity of features in an application, the features need to be consistently usable in real-world situations. This is even more difficult to achieve in today’s fragmented mobile ecosystem.
Automation is key to achieving speed across the pipeline. Every team—Dev, QA, and Ops—needs to commit to automating as much as possible. What this means practically will vary for each of them, but the commitment is necessary for it to really work. For Dev, build automation using Jenkins is the first step to automation. For QA, automating unit tests is the starting point. For Ops, being able to create and configure various environments according to a template is where it begins. Automation reduces manual errors, and bakes quality into every step of the process.
It’s important to think of automation in terms of a trigger-and-response model. Across the SDLC, various events can be used as triggers to initiate one or more responses. For example, every time a developer commits code, the event acts as a trigger for Jenkins to automatically compile and build the code. As a next step, Jenkins can integrate with a testing tool to initiate automated unit tests. Further, functional testing on real devices can be automated using a device cloud.
This way, teams get feedback on each step of the process effortlessly, and can spend more of their time on higher-value tasks. But best of all, automation brings a level of speed that would not be possible if humans were manually implementing the same tasks. Imagine buying a new Android device each week, or configuring every device manually before each test run, or ensuring all devices are running updated versions of operating systems and supporting applications. Automating or offloading these plumbing tasks to a vendor brings speed and quality at any scale.
Another opportunity for automation is the use of templates to simplify the creation of environments. If you use AWS for infrastructure, this would mean using a tool like CloudFormation that can spin up production-ready environments based on previous configurations, or templates you create. It’s a challenge to mimic production environments for testing purposes, but by templatizing the process, it becomes manageable, and gives you more reliable testing results.
With microservices apps, things move fast and break often. The number of alerts can become overwhelming if looked at in a steady unfiltered stream. The solution is to use a routing logic that ensures each person and team sees alerts that are relevant to their work. Alerts become even more valuable when they’re used as triggers for automation. For example, an alert about a failed service can be used to automatically create a ticket in Jira, notify the teams involved, and keep everyone updated as the status of the issue changes.
When automating the entire SDLC, optimizing each part of the process brings greater speed, but to take this even higher, you should think of your pipeline as a whole. As your automation matures, you need to consider how you can make changes that affect the entire pipeline. Tools like Spinnaker, created by Netflix, and AWS CodePipeline enable you to do this in a visual way. They make it easy and manageable to do canary releases, which can otherwise be daunting if you’re already struggling to release on a single production environment.
Looking at the pipeline as a whole helps bring all hands on board for automation. This is beyond just throwing in a few new tools. It goes deeper to consider the processes that these tools support. Deeper still, it looks at how teams work together and whether they are restricted or empowered by the tools and processes they use. A culture of automation across Dev, QA, and Ops is critical to achieving the speed that a DevOps transformation promises.
Building quality into your SDLC happens every step of the way. It requires input from every team, and requires a commitment to automation. You know you’re on the right track when automation is something you do not just to reduce effort, but to also move faster, and build quality in. As you embrace a culture of automation, it’s bound to transform your testing efforts and result in high-quality apps that are shipped faster. This is the promise of DevOps.
Twain Taylor began his career at Google, where, among other things, he was involved in technical support for the AdWords team. His work involved reviewing stack traces, and resolving issues affecting both customers and the Support team, and handling escalations. Later, he built branded social media applications, and automation scripts to help startups better manage their marketing operations. Today, as a technology journalist he helps IT magazines, and startups change the way teams build and ship applications.