Welcome to this lesson, in this course, we are discussing combining other agile methodologies with scrum to create a unique agile solution. In this lesson, we are going to discuss DevOps. So, DevOps is often wrapped into many solutions then where DevOps comes from a combination of development and operations, there is said to be a lot of conflict between development and operations and I agree with that. Development always wants to improve, add new features, fixed problems, develop new functionality and operations. They want to keep the product stable and running in a stable state. They don't want a lot of new deliveries, new releases, new deployments because it can add a factor of instability, possibly it could cause the system to go offline. So operations likes to keep the state of the product stable whereas development again and product owners, product managers, they want to continuously improve. So DevOps is a methodology for continuously delivering, continuously improving, continuously resolving issues, but also continuously stabilizing. So it's a methodology to support again, continuous improvement. Well at the same time, continuous stability, you can see here the bridge between development and operations and that's DevOps. So DevOps is definitely an agile methodology and it's a true way of thinking. No matter where you go, DevOps experts will say that it's a mindset and that is true. It's also a different way of thinking about product development. DevOps has three major components continuous improvement, continuous integration and continuous deployment with continuous improvement. That's where team members and stakeholders test the product, gather feedback to improve the product. They may be running it in, say, a staging environment and they are getting feedback on what new features can be added. Maybe they're getting feedback on what defects to resolve. Developers and security professionals also monitor new threats. New threats come up, new vulnerabilities are discovered and all members of the delivery team can contribute to the continuous improvement, continuous integration. So that's a practice of integrating or building the product components in small batches. Again, here is that small batches, again, if we build and we compile or if we integrate more often in smaller batches we'll have more success is so integration, means a working solution increments and that's what we want. We need that working solution increment, whether it's software or it is hardware software, some kind of a device, but we we need something working. That's the true measure of progress, building an integration occurs on a constant basis. Again, we want to have more successes and if we do run into a an integration that's not successful, we will have a very recent successful integration in order to use as a baseline for troubleshooting. Continuous integration in small batches allows for again more successful integrations to go through the system. More often it supports more integrated milestones and more opportunities for rollbacks and integration is very complex. Therefore more milestones, more baselines, makes troubleshooting less time and effort intensive and continuous deployment. So continuous deployment is the practice where the working solution or the working product is implemented to a let's just say, a production like environment. And this is not to say that virtualization and cloud is required or necessary. However, if you can make use of virtualization, if you can change your thinking to adopting cloud or virtualization there, it's virtually the same thing. We can make copies of our production environment as many as we need or with their own identities and we can deploy to these environments. And if we have a copy of the production environment, it's going to give us a much better test. We're going to get the best feedback because we're running, we're not doing an app, we're doing an apples to apples, test an apples to apples comparison. It's not an apples to oranges, also here we can see the workflow of checking into a repository, doing a build and test validating that we have an integration and then a deployment to a test environment. Maybe then ultimately a staging environment and then maybe an auto production environment. Obviously results have to come back to the team to decide how they want to proceed. But we can see here, we we also will get metrics and metrics are very important. We can see here, in this case which operating environments are passing and which operating environments are failing. But notice here we have two passing and this one is a failure, but that's okay because we can just compare the passing environment. The most recent passing environment with the failed environment and try to understand what went wrong same thing here. And even though we can't see here in this graph where this dashboard, the last successful integration chances are, it's not too far behind the failure. So we can troubleshoot and resolve it again with DevOps, failures like this are not not necessarily bad. And that's why we should report on them as often as possible, chances are that the amount of work that went into the difference between a passing integration and a failing is a small amount. And therefore the differences there can be figured out quickly and we can get another pass on here. So the stakeholders may see a failure or two, but they will see a passing integration not too long afterwards.
