[FICD] Faster Iterations through Continuous Deployment

• 0:00 - intro
• 0:00:30 - What's the difference between continuous deployment and release deployment?
• 0:03:14 - Continuous Deployment is closer to the GitHub flow
• 0:03:49 - Focus of continuous deployment
• 0:06:22 - Importance of verticals to continuous deployment
• 0:07:29 - where testing happens in continuous deployment
• 0:07:44 - Why is it important to talk about continuous deployment in composable architecture?
• 0:09:52 - Does every change to code go directly to production in continuous deployment?
• 0:12:51 - Advantages of continuous deployment as compared to release deployments?
• 0:14:43 - How does continuous deployment streamline deployment process as compared to release deployments?
• 0:16:36 - Evaluating risks in continuous deployment
• 0:19:53 - Key advice for early adopters
• 0:21:55 - Rollback processes and blue-green deploys in continuous deployments
• 0:22:41 - Summary

continuous deployment, continuous integration, devops, automated deployment, automated testing, release management, infrastructure as code, blue-green deployment, canary release

Hi. Welcome back to the Goodfrontend Show.

And today we're going to be talking about continuous deployment.

Kane, what is the main difference between continuous deployment and release deployments?

To begin with, probably it's helpful to start off with what deployments we're referring to here.

Deployments that we're referring to here is when you are pushing the code that you have done in development into production so that it can serve your customers.

So that's the deployment that we're talking about.

And the typical deployment that most enterprises have is what you call a release deployments.

So for those who watched our previous episode on Extreme GitHub flow. Release deployments, usually and typically they would follow a sort of git flow approach.

What I mean by that is that you will have your development branches, feature branches, you've got your main/master branch, your release branches, hotfixes and so on.

And what you tend to do when you want to deploy something to production, you would then tag the features that you want to be deployed.

You would give it a release number and you would deploy that release into production and then you would tell all the stakeholders to say,.

"Oh, in this release, these are the features that are covered."

So that's release deployments and really the focus of release deployment more is on rigour.

What I mean by rigour is that it goes through all these different environments.

It gets tested, you do whatever you need to do and then it gets deployed to production.

And sometimes some organisations this process can take a very long time and maybe they would release every two weeks or every month or some can release maybe weekly or so on.

Now continuous deployment on the other hand, the emphasis on continuous deployment is on speed of iteration.

It's almost like a reaction towards release deployments.

The idea of continuous deployment is that business stakeholders tend to complain,.

"Oh, why is it that something is taking such a long time when it's such a simple change?

I only wanted to change my banner and I have to wait for like a whole release cycle just for me to get my banner" right?

And so continuous deployment came about as a reaction to the needs of the business and the customers for them to be able to deliver value quicker.

So continuous deployment is the idea of creating a feature which is more closer to the GitHub flow,.

The Extreme GitHub flow approach, which is creating a feature, you merge it and as soon as it's merged into the main branch, it's production ready and it's already deployable.

Much of continuous deployment means that you automate deployment, so as soon as it's merged, it's already deployed to production.

So, one, release deployments, they focus more on rigour and correctness and quality, whereas continuous deployment focuses more on speed and iteration.

Is there a way to introduce or ensuring that the quality is there with continuous deployment as well, or is that something that you just have to live with?

That's a great question. That's a common objection for continuous deployment.

The common objection is, well, you're taking away all these environments, test environment, UAT, you know, and you're just deploying straight to production.

That's a bit of a Y-O-L-O, as in You Only Live Once, type of attitude, but that's completely incorrect.

It's safe to do continuous deployment.

First and foremost, the quality of your code is still the same.

Let me perhaps break this down.

In the early days of software, and this is why we have a reaction towards Monolith is that a monolithic application is a single deployment and you have this platform that you have to deploy.

So when you're deploying a monolithic application, you're probably making... you're having to do some database changes,.

you're having to do some changes into your search indexes, to your content management system.

You're doing lots of things, but it's a single deployment because it's a single application.

And so what tends to happen is, let's say I do a banner change, but because this whole thing is part of a release cycle.

that is designed to protect production from breaking, okay, a simple banner change has to go through the same cycle of rigour, okay?

So continuous deployment is not suggesting that every single part of your application goes to production straight away.

What it suggests is that for applications that are, better for continuous deployment. It should go straight to continuous deployment.

So examples of software that is better for continuous deployment are things like storefronts and content management systems and search.

These verticals are better for continuous deployment because the same level of testing that is required.

if you were doing continuous deployment and release deployment is the same anyways.

Added to that, you don't lose quality because continuous deployment is not about making a change, deploying it to production straight away.

Continuous deployment is all about shifting the activities left.

What I mean by shifting the activities left is that you do your testing earlier, you don't do your test in a UAT environment or what not.

You do your test when you create your pull request, you create a preview deployment of that pull request. You do your test there.

So by the time it reaches your main branch, that is already production ready.

The only difference is that the things that can go to production quicker goes to production quicker.

and the things that has to go through a slower cycle can stay in a slower cycle because you can separate deployments for different types of application in a composable setting.

So what I'm gathering is that test is still done, but it's just done earlier.

Yes.

As opposed to the release deployment where it's done on different environments and stuff like that.

Why is it important to talk about the continuous deployment in composable architecture?

I mentioned earlier this idea that in composable architecture we no longer have a single application.

It really is wise for organisations to think which parts of the application should be deployed independently in continuous deployment fashion.

and which parts of the application should be done in a more rigorous manner, because there are, let's say, it's not compatible with continuous deployment for one reason or another.

What I mean by that is, for example, if that piece of software requires a lot of manual configuration changes when you are doing deployments.

Or it requires databases to be taken down when you are doing deployments, then those are not suitable for continuous deployment.

However, for applications like storefronts whereby it connects to APIs directly in the cloud, these types of application are much more suited.

And so it makes sense that when people are moving towards composable, they think thoroughly and headless. Also, they think thoroughly.

"Okay, which parts of my application is suitable for continuous deployment".

Now for us, because we work as frontend devs, frontend engineers here at GOODFRONTEND, we always recommend that if you are doing a composable project,.

You will most likely be in Headless in a headless situation or in a Micro-frontend situation, and those applications should be done in a continuous deployment manner.

Otherwise you are not getting the full benefits of faster iteration cycles.

So it depends on the project.

So you can break down a big monolithic app,.

Break it down to different smaller apps,

And then then you decide which app would be best for continuous deployment and which app is best for release deployments .

And in continuous deployment, does every change to the code go directly to production?

Yes, if you want.

For example, for us, you know, with with our smaller projects, it goes straight to production.

We simply merge it and it builds and it deploys because we do our testing much, much earlier, right?

So again, in the GitHub flow, in the Extreme GitHub flow scenario, you create a set of changes, you create a branch, you create a pull request.

This pull request gets deployed in an environment and it gets tested. All the automation happens to it.

And once the code review is done and everything is approved by your peers, by your testers and by the business

It gets merged into the main branch and that is already deployed directly to production.

Now to some who might get nervous with this idea, you can still introduce gated deployment or you can introduce continuous deployment nonetheless with an additional environment.

And typically this is what we refer to as blue green deployments.

So what is blue green deployment?

So when we speak of blue green deployments, you think of the two colours.

One is blue, right? That is the version of your software that is served to your customer.

That is what the customer is using and you have a green version of your software.

The green version of your software contains the latest software and it connects to all the latest endpoints that is of production.

The difference is this one is customer facing and this one is like not yet live, but if you are happy to make it live, what you can do is you promote green.

To become blue, you demote the blue environment and eventually you can kill it off. So.

The idea of a blue green deployment is it just gives you an additional safety.

So let's say you merge something into production that automatically kicks off and then it creates a green environment.

And what you can do is if you're not comfortable that going to live straight away, you can do sanity checks on your green environment.

And if everyone is happy, you just switch a button, right? And in a few minutes it will be promoted into the blue environment.

And the blue environment can live for a few hours or days.

However, you're more comfortable with and your live.

And if things don't work out with that latest version, then you can take back or roll back the original blue.

Okay

So you can either choose to deploy continuously as the word says, continuous deployment, or you can continue to do continuous deployment.

But the turning on of those features is a manual turn on.

What advantages does a continuous deployment offer compared to release deployments from the ones you've already mentioned?

Yeah. So just to reiterate,.

Firstly, it's a streamlined process, right? It's simple.

So the fact that you have your code changes, you push it straight into the main branch and it goes to production. It's a streamlined process, so it's simple.

Secondly, it's faster because there is just less red tape in the middle between the creation of the code and the serving of the customer.

So that's again, that's the advantage.

You take off all the red tape in the middle. That is not necessary for certain types of software for you to be able to do things quicker.

And because you're able to deploy this code quicker

That means that the feedback loops and the iteration cycles are also quicker, right?

So you can get feedback straight away from from the users and you can iterate on those features a lot quicker.

So deployments becomes a lot more natural, you know, So as soon as something is developed, rather than waiting for weeks and months before you see this feature, you see it straight away.

As soon as you see on the board as it's done, you know, you don't have to wait for a long release cycle.

You just have the feature straight away in production and you can iterate over it continuously..

So just to summarise that, it's simpler because it's there's less setting up involved, it's faster delivery of software and then you get quicker feedback loops and iteration cycles.

yes, exactly.

So like in what ways does continuous deployment streamline the deployment process compared to release deployments?

Similar to what I mentioned, is to do with the fact that there is just less things in between the created code and the customer, you know?

So one way I can describe this is a bit like Chinese whispers. So when we're talking, I'm giving you information straight away. This is continuous deployment.

You ask me and I give you the information straight away. Release deployment is a bit like Chinese whispers. Whereby I tell, let's say, another person. A consultant or what not.

And then this consultant tells the salesperson and then this salesperson tells the client what needs to be done.

You know, there's a lot more points to reach before the actual value is delivered.

But in the case of continuous deployment, it's a streamlined process that means, the information that you need is given to you directly from the supplier.

Rather than going through so many different gates.

What about the risks? What are the risks associated with continuous deployment that may not exist in the release deployments?

Since there's like checks, the less checks involved in the middle.

Are there more risks in deploying something like bugs in production compared to release deployments?

There is risk, but I would say it's the same amount of risk as if you were doing it with a release deployment process.

Now, the problem I would say with release deployments is this false idea that you think you're releasing quality software because it goes through more environments.

In reality, however, those environments are different. What I mean by that is that they have different databases, they have different content

They have different search configuration, they have different payment methods configured and so on.

And so what tends to happen is that you create your software in your local environment as a developer, you release it into, let's say, a test environment,.

Testers test it and then they find bugs and then you fix it and then you then deploy that piece of code that came from the test environment to your SIT and UAT and people find more bugs.

But really, the reason why they found more bugs in the UAT version is because it's a different configuration.

Maybe the content is richer, maybe the products are configured better, maybe there are more payment methods and so on.

So there is this feeling that in a release deployment cycle there is less risk because every stage of the process you're finding bugs and you're fixing it.

But that's only because those configuration, those environments are configured differently and so you simply don't see the bugs in the lower environment.

And so what we're doing in continuous deployment is that we're saying, actually all this environments in the middle between your local development,.

Your preview development or your smoke environment and production is actually pretty useless because they don't represent real production data and real production environment.

And so you simply deploy straight there and you test in that environment, right?

And if you're if you're concerned about introducing bugs, you can introduce green blue deployment.

And this is a very common thing. Even if you were using release deployments, people release to production and they still have bugs.

Why is that?

It's because the production environment is configured differently to their UAT environments, and so the bugs never really surface until they get to production.

But all you're doing in continuous deployment is saying, You know what, actually, I realise that all these environments in the middle are absolutely useless.

We will squash them so that we can have faster iteration cycles and we will be able to see the bugs straight away and fix them.

So, what is your advice to teams looking to adopt continuous deployment?,

Continuous deployment definitely is not for the faint hearted.

It's not for junior engineers, because continuous deployment could mean you push a code and it goes live straight away, even if it's gated. Right?

Even if you have a blue green, you push code, it goes live.

And so my key advice is, probably it's helpful for people to start adopting the Extreme GitHub flow processes,

And that is the processes that happens before continuous deployment and that is shifting everything left and doing everything in the pull request.

And so certain pull requests, for example, require more rigour, right?

So you maybe run a load test on that and a security test because you think, okay, these are big changes and we need to test this heavier before we deploy it to production.

And so you need to start thinking about Extreme GitHub flow processes. When you're thinking about continuous deployment.

You can't have continuous deployment without Extreme GitHub flow processes, otherwise you're just introducing bugs to production.

So it's definitely not for the faint hearted.

The idea is you shift everything left. You do things a lot earlier and you do everything in the pull request.

If you need to do something, you do it in the pull request. You don't do it in the main branch, you do it in the pull request.

Secondly, one thing that I would suggest that people have as part of continuous deployment is also a continuous monitoring culture. So we have things like, for example, New Relic or other APMs that allows you to monitor the health of your application, right?

So monitoring is an important concept, but that is something that everyone has today anyway.

You have to be on top of monitoring and for continuous deployment.

Understanding that a rollback process is clear is good also.

So the likelihood is you probably won't need a rollback process because the iteration cycle is very quick anyways.

You know, let's say there's a bug, ah okay, there's a bug, let's create a PR and let's merge it and let's go live straight away.

But nonetheless, it's important. Even if you can iterate quickly, sometimes you might need to roll back.

And so understanding rollback processes and blue green deploys is important as part of continuous deployment.

And lastly, the other item that's I would say people need to think through probably is understanding backward compatibility code and feature flagging.

When you are doing continuous deployment, you have to bear in mind that everything has to work without manual changes.

And so understanding how to turn off features through feature flagging and backward compatibility coding is an essential part of continuous deployment.

Just to summarise.

First is to incorporate Extreme GitHub flows into your workflow in order for you to be able to get into continuous deployment.

And then the next thing is to monitor, monitor your application and then looking into the rollback process as well.

And then lastly, feature flagging..

Yeah, and backward compatibility.

Backward compatibility

Yes.

Oh, there's one thing that I forgot to ask earlier. The complexity in initial deployment?

Yeah, complexity wise, I would say that it depends, to be honest.

If you are doing a blue green deployment that can be slightly complex because of course you need to understand what will become green or what is always pointing to blue.

What I mean by that, for example, is if you are, let's say you are creating a green environment,.

Thus the green environment point to a green content management system, green commerce solution, green search provider or what not.

Or do they all point to the blue?

So understanding what is green and understanding what is blue can be a little complex to set up because your application has to be flexible to almost point to production or staging anytime you want, right?

So there are those complexities.

But again, when you are doing the released version, also there are complexities but just in a different way.

So both are complex to set up in their own ways.

It's really just down to thinking about what type of application is this? .

And is this more suited to continuous deployment so that we can get faster iterations?

Or is this application more suited to release deployments so that we can have rigour?

And usually that boils down to time to market.

If you want something quick, then it has to go through continuous deployment.

However, if the cost of deploying something bad is really high, then you put a lot of rigour towards it.

So for, for example, for many banking applications, I wouldn't do continuous deployment because if the cost of it not working is a lot greater than iterating quickly.

However, for a lot of e-commerce software,.

A lot of more content management, all this stuff, you know,.

To iterate quicker is a lot more important than rigour.