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.