In this episode you will learn about the different types of DevOps Practices
Continuous Integration (CI) — Revolves around what is going on at the master branch of code and the ability to test it right away. So running tests throughout the entire build cycle. The whole point is to test first, and test often — investigating every piece of code when it is created and not at the end.
Continuous Delivery (CD, Staging) — All the processes are automated until you are ready to deploy to the user, which is a manual push to users.
Continuous Deployment (CD, Production) — The difference between Continuous delivery and continuous deployment is an automated process, companies like Amazon do this.
Full Transcript Below
Hey, everyone. Welcome back to Whiteboard Friday on our series of how to win DevOps through continuous testing. And last week, we talked about what DevOps was and give a little brief overview of what that is, kind of help you understand when you’re looking at articles, or you’re hearing about that at workplace.
And then today, we’re gonna be talking about the different types of DevOps practices. And the first one that everyone needs to be aware of is the acronym of CI, which I’m guessing you’ve probably heard about. This is before but it really stands for continuous integration, and what it does, it really revolves around what’s going on at the master branch of the code, and the things are actually happening to that master branch.
And what I mean by that is if you got developers who are all developing, and they’re merging their code back into this master, well, what you wanna be able to do is after something happens to that code, you wanna be able to immediately build and test it right away. And the way people do that is that they have continuous integration tools that after a merge has happened between whoever developers that are doing this, after a merge has happened, what will occur is that the continuous integration tool will recognize that and go, “Okay, well, I’m gonna build the software and I’m gonna look to see if the build is completing. If the build fails, I’m gonna report back to the master branch and notify everyone, ‘Hey, guys and girls, this is broken.'” Right, that something happened with the build, we need to go back, refactor, and make sure it works, right.
The next thing is if the build completes, then we’re also gonna be running tests. these are unit tests, these are automated tests as well. These would also be tests that are involved with that CI pipeline that you have, right, that were manual, that are automated now. And this getting same thing, so you look and say, “Okay, oh, if some of these tests have failed, I’m gonna report back to the master branch,” And so the more refactoring needs to occur. And the whole point of this is to test first and test often to get sure you’re getting that feedback to your developers, without having to say, “Hey, we coded everything and now let’s test it after three months of coding.” No, you wanna be able to make sure that everything is checking out as you’re going through each area of connect [SP] code to make sure your again what we’re, now, we can actually deploy to production.
So now that we have covered what CI is, now we really wanna talk about is…now that the tests have actually passed here, right, what are we gonna do with that, right? You could say, “Okay, well, we got all our automated tests are passing, now we’re gonna do some UI-type testing or design testing.” Some testing is really hard to actually automate, right. Well, what you could do is if you’re using something like continuous delivery, is that when you’re actually going through the same pipeline where you’re coding, you’re doing the unit test, you’re integrating the test, you’re getting to acceptance test, you can insert different types of testing before you actually deploy it to production. And the thing with continuous delivery is that all these processes are automated, until you get to a point where you’re actually gonna deploy it into a user. Either the user could be somebody into production or it could be into a UA [SP] team environment, a QA environment, whatever that is, right. You wanna make sure, when you’re deploying it, it’s deployed to a particular base.
The other thing is that again all this is automated except for this part, which is a manual step, so we talked about last time, which is our push button approach to DevOps. Well, what would occur is that at this point, this is where that push button would be and you have to decide, you wanna push it manually, or if you’re getting into a continuous deployment model, this will be an automated approach. So the really big differences between continuous delivery and continuous deployment, is that when you’re getting to deploy it to a end user base actually, go often and give back to test or even out into production, continuous deployment is an automated process that occurs and this is done by other tools as well. Our old illustrations [SP] type tools that will pick up, “Oh, all these tests have passed, deploy automatically.”
If you look at how some of the companies out there like Amazon, they are amazingly fast at how they’re actually deploying into production. If you look at the statistics of how they actually do that day in and day out. So again, quick differences, continuous delivery to manual push to a user base or into production, and continuous deployment is usually most often an automated process as it gets deployed over into production. So that is kind of our talk today about the different types of DevOps practices and continue on, we’re gonna be talking about more continuous testing in our next our next Whiteboard Friday series.
Hey, everyone, Ryan Yackel here with QA Symphony. Thanks for watching Whiteboard Friday. If you wanna learn more about QA Symphony, make sure you go to qasymphony.com. There, you can sign up for a free trial of all of our products, and you can go to our resource section where we’ve got our blog, upcoming webinars, all things related to testing. So thanks again for watching Whiteboard Friday and we hope to see you soon.