In this lesson, we are going to talk about some other principles of the DevOps methodology. We briefly touched on this in our previous lecture. We talked about Cloud and virtualization to have as many identical environments as possible. Cloud and virtualization are almost the same thing. Cloud is a collection or an ability to spin up virtualized environments, but again, big part of DevOps is managing all of these, making sure that all of our Test and Evaluation environments and development environments are identical to production, so, we always have two apples testing an evaluation and development. Automation. So we can automate several different types of processes in the DevOps space. These are some tools here that help us automate deployment to various Cloud. We can have a public Cloud, we can run with such Clouds as Amazon, Google, Microsoft. Automation is a great way to go because it does also allow teams to be cross-functional. The more you automate, the less you have to know about the process. If we can get it down to just running a script or a button click, really anybody on our team should be able to do that. Automation for Deployment, it really strengthens your process and is a certainly as prescribed by the DevOps methodology. Here's something interesting, separation of deployment and release. If we make these separate activities, it gives us an interesting result. It really gives us the ability to more closely unify development and operations. There are several different approaches. Things like feature flags where we can hide features from a typical user so we can deploy the new version of the application, or the software on the device, or on our production environment. However, it can only be accessed by either key consumers, data users, or the development staff. The feature toggles are just putting logic around the features that they're only accessed by who we want it to be accessed by. In this way, the features can actually run a production. We can validate that they're not causing problems, and when we are ready, we can turn the feature toggles off and then make the announcement of the release. Another way to do it is what they call a canary, that we have a stable release version and then we have a canary version maybe in a different data center who are two different adopters. Here we see that the operating environment are different names, so, we have the next version here. This is a test version and we can validate here if this indeed runs fine on the production environment. Separating, release, and deployment, it's an advanced practice. The practice hinges on quietly or secretly deploying features to the production environment without making the announcement that the new features are up and running in production. Then again, this allows the operations people to begin to get measurements and begin to validate that everything is running fine. Then it makes releasing more of an announcement or a business process rather than a technical process. All the technical processes surround deployment. We've been deploying because we'd been using identical environments for testing and staging, so, now we just take on a bit of a different way of deploying to our live environment, and these are just some ways feature toggles and canary releases and there are other methods as well. This makes releasing more of a process of an announcement and management. We can see here that we're able to deploy to our live environment. We have a period of metrics and then the unannounced features have been running a production and then we can make the announcement of the release at the appropriate time, or we could send out some, either an email or send out a message in some way again. Then release becomes more of a management and announcing process. After this period of metrics, again, we make the announcement that the new features are running in production and can be immediately accessed by the user community and then we can release our paperwork. However, we must always use telemetry. We must always monitor for any kind of defects, we must always monitor for security. Operating systems: Sometimes vulnerabilities are found later on or are as we go. So once a product is released, the Ops team must continue to monitor using telemetry. Telemetry is a fancy word often measuring things we can't see. Teller is far, Metry is metrics. We are looking for issues such as maybe a log file was filling up. That's not immediately obvious or there's some new security threat. The metrics ensure that the product performs as expected. The security team keeps track of newly discovered vulnerabilities and threats. If appropriate, the security team may need to plan a vulnerability mediation. Maybe a security fix will go through the same separated deployment and release process, but it's very important to go through these once released continue to monitor particularly for security, because security is such a big of vulnerability, such a big threat and a big risk now. Again, the test first can continue to be used. It does not have to be just a developer type of approach. We saw how DevOps can be applied to just the development team but our scrum team is more than just our development team. It's our product donor, it's our developers, it's our testers, and it's our stakeholders. We can use test first, obviously for deployment and releasing as well. Again, the test first, this is the traditional V-model that for every feature, we write a feature, we write a test. When we write a story, we write a test, we write code, we write a test. However, in today's approach, we immediately write a test right next to it and we can use behavior-driven development to continuously validate it. We write a story at the same time we write a test, and again, we can still use behavior-driven development. When we write code for our stories or features, we immediately write the test at the same time and we can use test-driven development. This allows us to always have a test. This allows us the maximum flexibility for automation. Automation is big especially for regression testing because there's not often time to go back in regression test. But if we automate, we can run those automated regression tests all the time. Well, the testers focus on the newly written stories and features.
