Transcripted Summary
Let's talk about DevOps.
You may be familiar with the Agile testing quadrants, which were originally developed by Brian Marick. Janet Gregory and I have used this a lot in our work.
The quadrants are a taxonomy of different types of tests we may need to do to feel confident about our product.
We have technology facing tests, business facing tests, tests that guide development and tests that critique the product. DevOps crosses into all four Agile testing quadrants. It's a whole team approach that's not only continuously delivering but also continuously operating and learning about a software product.
DevOps expanded the whole team responsibility for quality.
In larger organizations, even after they adopted Agile, operations was often still siloed, and we were throwing code over the wall basically to operations to release it and take care of it in production. But, in recent years, advances in technology and practices showed the value of continuous delivery, making these small and low risk changes out to production frequently, even many times a day.
We have new tools now to manage our test and production platforms so that creating and maintaining the infrastructure necessary is accessible to more team members.
In this chapter, we'll build a common understanding of DevOps, continuous delivery and deployment, why automation is so important for this and some terminology to help us talk with our teams about it.
I'd like you to stop and think for a minute and maybe even pause the video.
When you see these terms — DevOps, continuous delivery, deployment and continuous testing — does it sound like you're going to be on a hamster wheel and just never stopping? It sounds scary, but it's really the opposite.
Collaborating with the whole team to get value out to our customers more frequently at a sustainable pace benefits all of us in it lets us enjoy our work and do a great job for our customers.
The whole team approach helps us build confidence that frequent deploys to production won't cause problems and will add value. Having these diverse competencies and experience on the team means that we can solve automation problems quickly.
I recommend Lisi Hocke's course, The Whole Team Approach to Continuous Testing, especially Chapter 2 to learn more about this.
As testers and other members of the team, we need to learn to talk DevOps with each other and people who might be DevOps specialists on the team. And we can help them learn about testing as well.
Testing really is the heart of DevOps.
It's about collaboration, continuous learning, continuous improvement, and it's a culture.
Agile and DevOps both require a cultural change, and we know that's hard. By learning the terminology and the concepts, we can start to understand the culture and become part of it.
Let's start by talking about continuous integration.
This is where developers integrate code changes into a shared repository, one or more times per day, so that we're all working off of the same code base. And then each check-in is verified by an automated build, which allows the teams to detect problems early. We may do frequent production deploys, although not every change may result in an automatic production deployment.
We talk about continuous integration.
You'll hear people talk about whether it should be done on trunk or master or whether you should use branches. We're not going to get into that discussion, but I encourage you to see trunkbaseddevelopment.com if you'd like to know more about that.
Deployment pipelines are kicked off by continuous integration, by checking in new changes.
We need to identify and fix any bottlenecks in our pipelines to preserve our value streams and give us our quick feedback that we need.
- It's a team decision to decide if a given stage should run. If the unit tests fail, do we want to stop our build pipeline? Probably so.
- If some of our automated acceptance tests fail, do we want to stop, or do we want to continue? That's a team decision.
I really like the continuous delivery principles because they really fit in for me with Agile development.
Build quality in, work in small batches, computers perform repetitive tasks, and people solve problems, relentlessly pursue continuous improvement, and everyone is responsible. You can find out more about that on continuousdelivery.com.
As we're going through our pipelines, we're committing new changes, which could be features, configuration changes, bug fixes, experiments like A/B testing and getting those into production. It heavily benefits from test automation, automated regression tests, but it's not dependent on those. We'll talk more about that in a minute.
Here's a continuous delivery pipeline example.
Notice the color coding here. Some of these steps that are in yellow are manual and, yes, those are part of your pipeline. I was really surprised when I learned that.
Things like exploratory testing are really critical to feeling confident about the new features you're putting on in production.
We may also run some of these stages in parallel to speed up our pipeline and speed up our feedback loop. You may have more than one pipeline. You may have separate ones to go to test environments, staging environments, production environments.
Continuous delivery, you're going to get a release candidate that could be deployed to production if all your tests pass and all your stages pass, but it's a business decision whether to actually deploy it.
In continuous deployment, the deploy to production is actually automatic.
Every commit that gets through the build with everything passing and everything successful will be deployed to production.
Does that mean customers will see it right away? No. Deploying is not the same as releasing. We'll use feature toggles and other techniques to hide the features tool ready for customers to see them.
We mentioned that automation is not strictly necessary. I have known teams that did continuous delivery without it, but we've learned from the State of DevOps survey — and I highly recommend this book, Accelerate, which is about several years of findings of that survey — that reliable automated tests created and maintained by developers is a predictor of high-performing teams, along with testers being there to collaborate with developers on automation and also to do exploratory testing and more testing activities.
I highly recommend that you and your team read this book.
One of the terms I'd like to get clear, as you might hear it, is the “Blue-Green Deployment”.
This is one of the ways that my teams have been able to manage risk when we try to do continuous delivery.
With blue-green deployment, you actually have 2 production servers, and they could have identical code on them but only one of them is live.
Our DNS router is sending all the traffic to one server. In this case, let's say it's the blue server.
Our green server currently is idle, but we, the team, we can get to our own server because we have a specific URL for it. That allows us to deploy our latest release candidate to the idle server. We can do testing on there, be confident that everything looks good in production, and then we can flip the switch and point our router now to the green server, and all of our customer traffic will go there.
If we do have a terrible problem that somehow we missed and customers start to see a terrible problem, we can simply flip the switch back and point to the old production code that's still on the blue server.
That really helps us limit customer pain in case something bad happens. There are lots of things like this to help us manage the risk with continuous delivery and deployment.
We're going to talk a lot more about terminology, and the idea is to help you learn the language to communicate and collaborate with your team. Think about the relationships that you need to build. Who can help you with test automation?
Remember as we're humans, connecting with people on a human level is really important. It may take a lot of courage to ask for help, but it's important that we do this because we're taking on a big responsibility here along with our team.
Asking for help is a great way to make friends and build bridges.
For example, I might ask an operation specialist to come explain the deployment pipeline to all of us testers, so we can understand it better, and we might even be able to ask questions and make suggestions about it.
We might ask a developer to come explain high-level systems architecture to the new people on the team. These activities help you build trust and build knowledge.
I've got a lot of great resources here. I encourage you and your team to go learn more about these concepts and get into the details.
In our next chapter, we're going to talk more about what's in your pipeline.
