Home / IT & Computer Science / Business Technology / Microsoft Future Ready: Continuous Integration Implementation / Full DevOps
Full DevOps
.
Hello, and welcome back to this module on continuous delivery to continuous deployment. Well done. You’ve made it through three modules. And this is a module which takes you all the way from delivering on a continuous fashion in production, but through the change approvals and through someone actually pressing the button manually for you, to a fully automated process. This is fully DevOps right? This is what this DevOps all about. It’s about having a process that allows you to go out to production constantly deploy. And remember constantly deploying something does not mean constantly releasing something. And the difference entails a whole new structure of practises that you need to follow. Practises such as, feature flags. Practises such as, phased rollout.
Practises such as, experimentation. And that’s exactly what we plan to cover in this module. Now, just to set the context, the key difference between continuous delivery and continuous deployment, as you can see on the slide is continuous delivery is all about having a pipeline. But the step before releasing into production means you have a step approval process. And that step approval process in certain organisations could be a five minute job, could be a five day job. So, sometimes it takes a long time to build that trust with the leadership team or the product owners and the product managers for them to allow you to roll out updates and deployment as in when. But that is the nirvana state.
And that’s what continuous deployment is. Continuous deployment is being able to just commit your code, have a high-quality build output and artefact that gets added into a release train. And that release train goes all the way out into production. Now the unicorns, and when I say unicorns I mean the Netflix, the Facebook’s and these companies that have redefined how technology works, have been doing these Practises for a number of years now. But you can see more of these Practises are becoming the norm in the industry and a lot more organisations are on-boarding them. And so when you go in a conference and say, we release five times a day.
It doesn’t have the same impact anymore as it used to a few years back. But when you go to a bank and say, we release five times a day how many times do you release? They’re like, whoa five times a day. We probably do one release in five months. So for them to make a journey all the way to continuous deployment is quite a big challenge. And they have to go through the phases that we have talked about. Get the CI right. Make sure the CI is reliable. It’s one that you believe in and one that you want to improve on. Then get to the continuous delivery stage. Make sure you have the right quality factors built in.
Make sure you can validate that you have a good tangible product before you roll it out with the right approvals. And when you’re at that stage, you go full monty with continuous deployment, right. That’s what DevOps is all about. So I’ve changed this picture again for module 3 as we’ve covered CI build automation, deploy and test automation. We’re going to focus on some of the Practises of continuous deployment. And one that I’m personally very excited about is feature flags. And one that the product really allows you to do very easily now is stage deployment. Stage deployments, you could do right from release management where you could decide to roll out updates to selective instances.
But Azure supports it quite broadly within web apps, wherein you can select and set up slots and then leverage those slots to phase in phase out releases. And then at the tail end of the course we’ll look at app insights on how you can put up insights to work to get real time telemetry back from production. We’ll also look at a nifty feature available within app insights, that gives you the integration from Visual Studio team services and Azure to put a marker on app insights. And it’s called release annotation. When you look at the data that comes back from production and things don’t work out the first thing you ask is, did a release just go out.
And that’s what releases annotations are. They just put a marker on your telemetry to say, this is a point where the release went out and if after that point you see traffic going down or traffic significantly going up or certain exceptions or certain things happening then you know that there’s something fishy about this specific release. And that’s an action point you can take away and investigate. So you know Practises for continuous deployment like we talked about in continuous delivery, there are some industry standards and Practises and the same applies to continuous deployment. Now I’ve listed some here. This just assumes that all the Practises that we talked about when we talked about continuous delivery still apply.
This is just stuff on top of that. And continuous deployment is about having an architecture that is microservices based. As I talked about previously, you cannot have a– you cannot have a monolithic application and service it in real time with multiple releases and deployments in a day. Simply because every time a monolith goes down there’s a big impact. But when a service goes down there’s less impact. So that kind of architecture is more balanced and made for a continuous deployment mode of work. Work on a minimal viable product approach, MVP.
It’s good because it allows you to focus your attention on getting the most bare minimum done to get a feature out deployed and then start getting feedback from the field on whether it hits the mark of what was expected from it, whether you can evolve it further and where there is scope for improvement. What you don’t want to do is go build an Eiffel Tower and figure out that your customers didn’t really need an Eiffel Tower. They just needed the Seattle Needle. And it would be too expensive then to go back and fix it. The other practise is never rolled back.
In this mode of work where we’re talking about constantly releasing and deploying stuff we can’t have a rollback condition. Rollbacks don’t work. In a mode of continuous deployment you are immutable in your delivery you have to fix it. And the process needs to be quick enough to allow the fixes to roll out as soon as they’re ready. You cannot be successful with continuous deployment unless you have a way of measuring things that are happening in production in the live site. And that’s where things like Operation Insights, App Insights, telemetry diagnostics are really, really useful.
And with more of cloud platforms taking on this role you would see they have native tools available that give you the high level and the drill down view of telemetry operations insights, applications insights. And then they allow eventing for when things happen, for things to happen. Which means, if the infrastructure is damaged self-heal, go restart, go do this, go run the script, which kind of helps you have the first level of checks and balances in place even before the issue gets to you. And you kind of need that if you want to move into a continuous deployment mode. Metrics.
Have you ever had that conversation with someone who says, oh we want to track what is the velocity of your team. And you’re like, how does that help you in any way. What you should be measuring is a product level KPI. How many customers are moving onto the new version of the platform that we’ve rolled out? How many customers are buying the new features that we’re developing? How many customers are becoming free to pro? These are the kind of metrics you’re interested in. And when you start measuring those business metrics in IT then it becomes a view of let’s join up to deliver a product rather than let’s join up to deliver a part of technology.
And organisations that go full continuous deployment move away from just these mundane technology-centric KPIs to more business focused KPIs. But it’s a cultural shift one that takes time to adapt. So let’s get to the techniques of continuous deployment. The first technique I want to call out here is feature flags. One that we will cover in a demo as well. Feature flags are amazing. If you want to be continuously deploying stuff in production you can’t have this condition where, oh I’m going to take a week to create this stuff so I’m not going to do a deployment for a week. Let me just add some plumbing, some server level APIs.
And let’s just hide that behind a condition and roll that code out into production. And then let me behind the scenes enable that feature just for myself, so I can keep invoking that API with production data to see whether it’s resilient, whether it’s giving me the responses I need, whether it’s going to be able to scale. And likewise you know, when we develop new features in an application we will only want to roll it out to a fair few to get feedback. We don’t want to have to like set up a test instance and invite them, because the chances of that happening are quite low.
But when you release in production and say, look, we’ve just released this new feature is private can you go and test it for me give me feedback? Chances of that happening are high. But all of that works on the principle of feature flags. And we’ll look at a couple of extensions that enable that. Will work through that in a demo. The next one here is blue-green deployments. You know it’s a good practise to have production like environments available. Where you can roll out stuff. So as it says here, blue-green is a technique for deployments where the existing running deployment is left in place, a new version of the application is installed and then a flip and a switch over happens.
So if you’re working in microservices, or if you’re using Azure Service Fabric, or any of those Service Fabric oriented technologies, then you would see it’s very, very easy to spin up a new host of your service, which has a new version of the software, direct the traffic to it and then flip it over when you’re kind of ready to roll it out. And that’s a very popular topic. And an approach that’s available within Azure through Service Fabric, through web app in the form of slots. The other technique that’s available is canary releases. And this is one that we’ll look at in a demo.
Which basically means you do a phased deployment where you patch a few servers first, adjust your load balancer such that some traffic gets routed out to it and then you can gauge whether it’s working fine. And if it’s all working fine then you just roll that release out to all the other environments. The last one in the list is DevSecOps. And you know I’m calling it out for a reason here. It’s because as we all move to this DevOps way of working, we actually forgot that there is another department in the organisation called security.
And unless you take them in the fold, you’ll still have a siloed organisation because trust me, the cost of a data breach today is higher than ever before. There is the financial cost, but then there is the cost of reputation, right? So if you are an organisation that is holding customer data and that customer data gets leaked then the amount of shame that brings to the brand is just un–
fixable in a way. And not having security on board means you’re exposing yourself but having security on board means you kind of have to wait for their manual processes to be complete. And they might not be as swift and as quick in their validations as you may be in your dev and operations rollout. But having some sort of an automated way, where you can take them in the fold in your own pipelines. Automate part of what security does means, you can actually roll out a release with confidence knowing that it’s yes automated but it’s secure at the same time.
So we’ll cover that off in one of the videos where we talk about some of the techniques and tools that are available to take off the DevSecOps in the continuous deployment cycle. So that’s it for the introduction. Join me. We have plenty of exciting technical content lined up in this module. Next we’re going to start looking at phased deployments with release management.
The previous step was an introduction to the final building block in DevOps, Continuous Deployment. We are ready to move away from delivering manually in a continuous fashion in production to a fully automated process.
This is what we refer to as full DevOps. It’s about having a process that allows you to go out to production and constantly deploy. But remember, constantly deploying something does not mean constantly releasing something.
Continuous Deployment Practices
When we discussed continuous delivery, we learned about the principles and practices of continuous delivery. Continuous deployment builds on the practices of continuous delivery. Continuous deployment is about:
- Having a microservices-based architecture
- Working on a Minimal Viable Product (MVP) approach
- Never rolling back
- Having real-time application and operations elementary
- Establishing meaningful metrics
Continous Deployment Techniques
Over the next couple of learning steps, we will look at the various continuous deployment techniques available to use. Here, we will provide a brief overview.
Feature Flags
A feature flag is a software development technique used to enable or disable functionality remotely without deploying code. New features can be deployed without making them visible to users. Feature flags help separate deployment from release letting you manage the full lifecycle of a feature.
Blue-Green Deployments
To minimise downtime caused by the cut-over between the final testing stage and live production stage of your software, you can make use of the blue-green deployment approach. With the blue-green deployment approach, you have two production environments, which are as identical as possible. At any time, one of them is live.
You typically prepare a new release of your software and do your final stage of testing in one environment. Once the software is working in that environment, you switch the router so that all incoming requests go to that environment. This means that the other environment is now idle.
Canary Releases
A canary release is a technique used to reduce the risk associated with introducing a new software version in production by slowly rolling out the change to a small subset of users before rolling it out to the entire infrastructure and making it available to everybody.
Similar to a blue-green deployment, you deploy the new version of your software to a subset of your infrastructure, to which no users are routed. When you are happy with the new version, you can start routing a few selected users to it.
DevSecOps
DevSecOps is an extension of DevOps and also falls within the agile framework. It incorporates security into every step of the development process. By taking security into your development fold, you can avoid costly damage to your organisation, not only financially but also reputationally.
Leave a comment, share an experience or ask a question to engage with your peers. When you are ready, click on Mark as complete and in the next step, you will learn about Deployment Groups and Release Management.
This article is from the online course:
Microsoft Future Ready: Continuous Integration Implementation
Created by
This article is from the free online
Microsoft Future Ready: Continuous Integration Implementation
Reach your personal and professional goals
Unlock access to hundreds of expert online courses and degrees from top universities and educators to gain accredited qualifications and professional CV-building certificates.
Join over 18 million learners to launch, switch or build upon your career, all at your own pace, across a wide range of topic areas.
