Imagine that three groups, each with different skills, need to get something done using all their combined skills. Should they a) work independently while keeping their knowledge separate, b) share their knowledge but keep their skills to themselves, or c) work together toward a common goal while sharing their knowledge and skills to help each other so that they can tackle any problem immediately using best practices? It’s not too hard to see that C is the ideal answer.
But let’s take a closer look at what this entails when the question regards DevOps and the three groups are development, operations, and QA.
The Agile Software Development Lifecycle
As we analyze these three departments and their responsibilities, let's first consider them in the context of an ancestor of DevOps: agile.
Development is the keeper of the code. They own the software, development, and automation, and their responsibility includes coding, making builds, deployment, and testing. The build manager owns the making of the builds and deployment. Code review is done pre-build via pair programming, followed by QA’s unit testing post-build every day before the last day of the sprint, which often emphasizes regression testing.
Operations is the keeper of the schedule. They have great insight into how each project fits into the schedule, whereas development and QA tend to have tunnel vision on the main project at any given point in time. Operations is skilled at monitoring, analyzing, and managing, and they are responsible for changes, deployment, and stability. Usually QA hands off the build to operations on the final day of the sprint.
QA is the keeper of verifying and validating that the system under test does what is expected of it. This includes dreaming up edge cases, making their expectations known, voicing any usability concerns, and ensuring that business needs and compliance issues are taken care of properly. They also are often responsible for business signoff, user acceptance testing, performance, and security.
There is a lot that can go wrong in this type of agile environment. The short daily build cycle and ten-day sprint seriously limit quality, complex development work, nonfunctional testing, and post-development support. Imagine that as an advertising slogan: "We get it done quickly, but …" Also, development and operations are dependent on each other without the control they need, which can lead to distrust. Between meetings and pair programming, a lot of the development team's day may seem to disappear.
Process Improvement through DevOps
DevOps implements a cultural shift to overcome these obstacles and streamlines everything as much as possible, with QA being the universal enabler.
DevOps can't be picked up by studying it independently; it needs to be experienced through immersion. It isn't about just the building blocks toward a solution; it is about the mortar that holds those blocks together. Interaction and collaboration is at the heart of how DevOps works.
OK, imagine you're the development team. Maybe you’re delivering pieces of new code several times a day; maybe you've got a big chunk that will take several days. You need rapid continuous testing with rapid feedback.
With DevOps, testing can be run quickly multiple times a day, even if QA is out having lunch. The QA team has acquired technical skills enabling them to build automation test scripts that can be prebaked into the build and deploy process. Nonfunctional testing (security, performance, etc.) is already baked into the test scripts, too, as well as into the way the programmers are taught to think when coding. Development automates the builds and environments, so no time is wasted stumbling around there.
OK, now imagine that you're in operations. What do you need? Metrics. You want to know the latest logged bugs, fixed bugs, and executed test cases, and you have gotten used to logging into 24/7 bug trackers and test management tools to derive them many times a day.
QA once again is proactive, and these metrics get delivered automatically after the automated test set quickly executes. Operations gets greater accountability, which they like. There are fewer production issues due to increased automation, which leads to more stability, which they also like. This leaves more time to focus on throughput.
For QA, this means a lot of skill improvements and role changes, allowing more upfront automation work, a greater focus on the testing process, and more follow-up time on education, continuous improvement, and continuous development. QA automates its testing so that development is not held up, automates metrics so that ops stays informed, and talks about behavioral testing in a way that gives dev and ops a common language.
The fun part is that there is never a sense of “us versus them,” where development or QA or ops get swelled heads about why their department is the special one. We all know we need to coexist, but now we visibly enable each other, especially QA (shhh—don't tell development and operations I said that last part). DevOps forces us to report the feedback each department needs from information we gather, as soon as possible.
The improved collaboration is really more of a cultural mindset change, leveraging shift-left, continuous delivery, and continuous improvement. Frankly, I don't know how a follow-up methodology can improve upon this model. Is there a way to force continuous innovation? Is there a secret weapon to make it easier to collaborate and play nicely with each other? How do you think we could improve processes in the future?
