Hi, I'm Eric Minick with IBM Cloud.

I want to talk a little bit about continuous delivery,

which is all about "how do I quickly get code into production?".

Continuous delivery as a term goes all the way back to the agile manifesto.

The first principle of that says,

"What's really important is that we satisfy our customers

through the early and continuous delivery of valuable software."

So, if we're in a place where we've got valuable changes to the code

(and if our changes aren't valuable, we probably shouldn't be making them)

but if we've got valuable changes to our code

we want to get in production, how do we do that?

That's what continuous delivery is all about.

Well, the first step here is that we've got code, not software,

so we need to turn it into software.

That's our build process, right? Good.

Now we've got software, we've got production, and we could just deploy the software into production.

Is that what we're going to do? No.

What we're really going to do is a whole bunch of testing

to make sure that what we have actually belongs out there.

So, most companies I work with have anywhere from 2 to 5 test environments.

They'll have an environment named something like "QA", right,

and another environment named something like "Performance" or "Stage."

Well, we can use those. Alright.

So, we take our software, we put it in the QA environment, we put it in the staging environment,

and we put it out in production.

Alright, and we should probably do some testing too.

So, this is kind of the backbone or the path to production in continuous delivery.

When you look at a continuous delivery tool, or you look at a continuous delivery pipeline,

you'll often see this kind of perspective: "I have builds and I put them out in production."

Now, what are the activities here? What are the key behaviors?

So the first one is this migration that we see, right,

so we can look at that migration, this migration, this migration,

and we say "Okay. This requires an automatic deployment, right?"

Auto deploy. This is where we see tools like application release automation,

continuous delivery pipelines, very focused on "how do my builds move through the environments?",

"what's the order of the environments?", "How do I manage and govern that?",

"Are there rules for when I need to move from here to here to here?" That kind of content.

The next side of this is it's not just about moving the bits, right, if we're just moving things around

the only thing that we've tested is that we can actually deploy our software.

That's valuable, but we probably have all these environments because

you know down in QA, in staging, we're doing some automated testing.

Right. Supporting a continuous testing kind of approach as part of our overall continuous delivery.

And then we're probably also using some tooling down here that we care about.

This would be our continuous integration server that does our builds, right?

The idea of a build manager or a continuous integration server have all come together.

So, here are the key pieces.

Final idea, typically in continuous delivery,

this transition here, moving from stage to prod,

is going to have another level of governance on it.

You might be in a fully automated situation where code commit comes in to Github.

There is a trigger that tells the build server "new code's here". It automatically does a build.

It triggers a deployment to QA, which automatically triggers our tests.

If those pass, we automatically trigger out to stage, which automatically triggers more tests.

That's great. It's continuous. It's fast.

When we're down here, when we're looking at this move to prod,

almost always were looking at some sort of a human getting involved.

Historically, that was your change approval board, your CAB.

Ideally if we're automating all of our testing, we're getting all the data,

we're able to automate the CAB out of existence and

just say "Hey look all the test passed, let's make a go/no-go decision here,

button's clicked, we moved to prod."

There may be some approvals out to a change management system, you might still have the CAB,

so there's something going on here with some decision making typically.

That's the basic idea of continuous delivery.

You have something valuable in code.

You want that in production, but you don't want to break things.

So what do we do?

Take our code, make it software in a build process.

Now we want to make sure we're not breaking, so we're going to test our deployment process, moving to QA.

We're then going to test the software with automated testing.

We're going to use the same deployment process to stage,

same deployment process out to production after doing more tests, more checks, getting approvals.

That allows us to get those changes into production quickly and safely.

And that's continuous delivery.

Thank you.

If you have questions, please drop us a line.

If you want to see more videos like this in the future, be sure to like and subscribe.