Define the physical DevOps process, including how to pick tools and cloud services.
- [Male] So now let's talk about setting up the physical DevOps process, or really, setting up the DevOps technologies. So, key things to consider include: automate as much as you can. This is about repeating things over and over again. This is about being consistent. The best way to be consistent is to leverage automation. So, in other words, leverage your DevOps tools to automate your development process as much as you possibly can to ensure consistency in terms of how you do development, testing, deployment.
Integration with the target cloud platforms is an absolute must, so they need to work and play well with whatever target cloud platform that you're leveraging for your DevOps environment, or leveraging for your target cloud deployment platform for your applications and data. The ability for your DevOps tools to work and play with Google, to work and play with Amazon web services, to work and play with Microsoft is an absolute must, and you have to build those capabilities into your design, as well as your tool set collection.
Keep the people in mind. Ultimately, this is about people, process, and technologies. And ultimately, people need to use these tools. They need to be happy with them. They have to use them on a daily basis. Listen to the developers, not only the DevOps engineers, but the people who are doing testing, deployment, operations, and ensure that the tools are living up to their expectations. Finally, don't fall in love with the tools. You're gonna be swapping these things out for the next five to ten years, and getting a tool in place that doesn't work out, that's not a big deal.
We can go ahead and replace it with something else, or do something else in terms of tweaking our process to make leveraging this tool easier, or levering some other technology. So, please don't fall in love with the technology. When we consider physical DevOps, we look at automation, and then we look at automating the software life cycle. Ultimately, how are we gonna take things in a repeatable way where we can leverage tools and technology to automate each step of the DevOps life cycle? This includes build automation and release automation, the ability to design, build, test, deploy, go through test engineering, continuous integration, things like that.
And then also leveraging the same tool set through the release automation process, the ability to continuously integrate, continuously test, and continuously deploy. There really is no demarcation line where I'm gonna stick one set of tools on one side, in the build automation side, and one set of tools on the other side, in the release automation side. We're gonna leverage the same tools across different automation approaches; build a release. And then ultimately, this is about ensuring that we're able to do build, test, deployment, release, operations, using a single stream of tools.
So, don't get caught up in something's on the build automation side or something's on the release automation side. This is about leveraging tooling that is gonna provide capabilities of both, typically; so build automation and release automation. So again, we deal with specifications, we deal with code, we deal with build, we deal with test, and we deal with deploy. Ultimately, this is about assigning tools and technology to meet the needs of spec, code, build, test, and deploy. However, as I mentioned earlier, we're gonna have some tools that span all five, some tools that span one, some tools that span two, three ...
This is about not necessarily putting tools in a particular silo, but this is about leveraging tool sets that are gonna be able to automate these processes on your behalf. When we look at spec, code, build, test, deploy, we have certain things to consider. Spec is about continuous design; the ability to design the system over and over again as needed. In other words, a user will externalize an issue to us; something's too slow, something's not meeting the business process, something is in need of change.
We're gonna go ahead and design the change of the spec at the spec phase. Next, we're gonna code. In other words, we're going to basically code the changes that are needed to be made within the application. This is continuous development. In other words, we're gonna do this as often as we need to, just like we designed as often as we need to. We're gonna do continuous integration around the build process, ensuring that everything works and plays all together. We're basically dealing with the configuration and tracking the configuration. We're going to test the application, ensuring that we're doing continuous testing so we're testing the application for security, for performance, for stability; all these are really built into the automated testing tools.
And then, finally, continuous deployment; the ability to deploy systems over and over again. As it goes through the design, development, integration, and testing phase, that there's an automated process to push it out into production, and therefore, operations; hence the term DevOps.
- DevOps on the cloud
- Continuous delivery, testing, integration, and deployment
- Creating your own DevOps processes
- Defining logical and physical processes
- Selecting cloud services: AWS, Google, Microsoft, and others
- DevOps use cases