Continuous Delivery Foundation CDF Webcast, 5 Aug 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: An Intro to CI/CD

Description

Presenter: Jason Odoom, Cybersecurity Engineer @ Booz Allen Hamilton

This webinar will present an introduction to the DevOps CI/CD process while providing a brief demo using Jenkins and other tools such as Artifactory and Ansible.

The topics that will be covered are:
- What is DevOps?
- What DevOps isn't
- What is CI/CD?
- A brief introduction to Jenkins
- How to implement a DevOps process

A

Okay, all right, hello, everyone, uh I'm jason o'doom, I'm a cyber security engineer at blues allen and today I'm going to introduce you to cicd the whole cicd process. So here here's the content. Here's what we're going to cover today we're going to cover uh what ci cd is, what it looks like what it isn't developer operations, because I feel it's difficult to talk about cicd without talking about devops and then I'm going to go into the devops pipeline. What that looks like and also some deployment methodologies, and also why you should use ci cd.

A

So the first part is you know what is ci cd, so we have two parts we have ci and we have cd right. The ci stands for continuous integration and the cd is just continuous delivery. So it's how you take. You know uh the process or code code, and then you know you deploy or you deliver it and send it to uh production so that whole process is.

A

Cicd well, let's dive a little deeper into into uh what it means right code is committed frequently. That means uh you know every couple of minutes.

A

The reason why this is important is because it allows us to avoid uh merge conflicts or issues in the future and I'll get into that a little bit later, but not only uh not only do we commit it frequently, we also test it. The testing is really important because, as it moves through different stages or environments into uh to production, we have to make sure that any errors are caught before you know. The whole world sees them before the end product uh you know, is used.

A

Okay, so in order for this to make sense, we have to look at you know how things were done in in the past. So in the past you have two developers, developers you'd, have you know, let's say bob and alice and then they'd code together.

A

Maybe bob would work on the same uh document as alice without them knowing and then, when it's time to combine those changes or merge, merges what they're called then there'll be. You know, lots of merged conflicts, so essentially what bob and alice were doing was making changes the same specific part of the code and that just doesn't make any sense. If you think about it right because it's hard to track changes, if you, if you don't uh commit them independently, but if you try to commit them at the same time, it gets really confusing.

A

So in order to avoid this issue, that's why this whole process uh you know, was created. You know I like to think of it as philosophy. Maybe it's me being dramatic, but uh that's that's really what it is. You know it's more than just uh you know tools as you'll see as you move along. You know it's more than just jenkins, or you know, ansible or whatever it has to be this.

A

This process doesn't work without you know, if you don't have this process the tools, the tools are meaningless, so it's very important to have you know to put this in place, uh communicate with your teams. That kind of thing uh you know try to change the culture within your your business.

A

In order for this to actually uh work.

A

All right, so this is this is the new way. This is how we solve the problem. We're committing code, uh frequently right we're not waiting uh an hour or two we're not waiting for for days, we're doing it instantly. Whatever changes we make, we commit this way. It's also easier to track. This is actually what's recommended. When you, uh you know, when you commit something to you know, version control doesn't have to be bitbucket, it doesn't have to be github, it could be gitlab so whatever whatever your business decides to use.

A

uh This is what you do. You commit every single time. You make a change and then you push it right and then it gets tested and when that test passes, sorry you push it. It gets built and then that build gets tested and if that build passes only when that build passes, then it gets pushed to uh production right, but it really depends uh on you, because I've seen I've seen it uh differently uh different different. uh You know. Companies uh have have a similar process, but it's not always the same.

A

Some people would will choose to. You know get rid of that development, environment and just go straight to testing environment and then you'll have a staging environment. Then you'll have a production environment, so it depends on what works for you.

A

Alright, so this is what it looks like you basically have your source, your versing version, control repository.

A

It can be get lab, github or bitbucket, and then you you'll push it to dev or whatever environment, then it'll get tested and when that test, and if that test passes it moves forward, if it doesn't pass, if it fails, it's going to move backwards and it's going to get fixed and then move it forward forward again, then, you have your testing environment, which is always good to have right for quality assurance, and then you push it the station if the code on the testing environment in the test environment passes, and then here this is very important.

A

This is what distinguishes uh continuous deployment from continuous delivery between the testing, the station environment and the product environment. It's a manual procedure, so it requires manual approval. So in the previous stages, here we just saw automation from source. To dev to test is all automation. There are no human interactions.

A

This is why this is what makes the process fast, because everything happens by itself no one's intervening, but between here before we push the production, we need to check to make sure if it's good, we need an okay, and when we get that confirmation, then we push the production and now that I've mentioned that, let me show you what continuous deployment looks like all right. So this is not what it is. Cicd is not. This cicd isn't just tools, as I mentioned in the past.

A

Here we have continuous deployment. I know some, some businesses are doing this. You know, but this is also kind of risky, because what we're doing here is we're taking source, we're building from source and we're pushing to test, and then, if the test passes, we're going to push it to prod.

A

That's it we're not going to have a staging environment, we're not going to get users to play with our application and then we're not going to catch. You know additional issues, no we're just going to question right. The production is really risky, but you know, as I mentioned before, you have to do what works for you. Maybe you don't need that development development environment?

A

Maybe you just need to test it in the station and, of course everyone needs prod in my opinion, but you know: let's move on all right, so it's very hard to talk about cicd without talking about devops, so developer operations is where this this whole process comes from this whole. This whole process doesn't happen without you know devops, so cicd is the devops uh process, so you have people in development right and people in operations and they collaborate in the past.

A

They didn't do that and that's where all these issues you know arose so devs and people and ops collaborate and they work on this and they try to push their code out as quickly as possible.

A

But here's here's more information on developer operations, so we use the pipeline to automate this whole uh process. So, as you saw in the previous slide, when we had uh our our dev environment, we had the source uh box and we had the dev environment and you know all the other, all our other environments uh in between the source or actually rather the source that whole that source box represents the pipeline, for example. Jenkins, is you know, as a pipeline jenkins will build your app. It will test your app everything happens on jenkins.

A

The only thing that doesn't happen in jenkins is the deployment you as a business or as a person, choose what deployment procedure or application or method that you want to use and I'll get into that more a little later.

A

So yes, the pipeline is part of the process, but it is in the process like, as I mentioned, the process is this: is this quote-unquote philosophy and it requires people to come together to plan and decide what is going to work best for them?

A

So here's here's, how that looks like all right. So in the devops pipeline we have our ci server. Our continuous integration server, an example of that are jenkins. Travis ci, aws code pipeline jenkins is self-hosted. You can host that yourself travis as a service, so you know you you pay for that and what I believe there's a free tier also and of course you know everyone's familiar with aws, and then we have the storage repository.

A

So what the storage repository is. Basically we have uh when we build an application, we have an artifact. The artifact is just the result or you know the outcome of that application. You know the quote: unquote compiled version.

A

We push that uh that version or or the application to a repository sort of like you know how we store source code in uh bitbucket or gitlab, but there are repository uh managers created. You know just for this, so we have jfrog artifactory. You can even store them in s3 or even docker hub. If you're building dark containers, you can tag them appropriately to manage different versions, but then how do we move these artifacts, these versions, from the repository to production or whatever environment that we want to deploy to?

A

And that's that's where you know the cd platform comes in. You have to choose the cd platform that makes sense for your for your business, for your order for your application, your workflow, so we have many uh different options such as ansible, spinnaker, circle, ci, gitlab or you can even use github ansible is pretty uh pretty painless. Spinnaker is feature-rich. You can do a lot of things with that and here's more uh details on what that looks like so to break it down.

A

uh Think of this as more of a detailed image compared to the previous one, I showed you uh with you know the whole box method, so we build the application from what we pull from source control. Then we build from source when we build from source. We execute those unit tests and this part will look different depending on you know, teams.

A

You know, I know you know. Most teams aren't running unit tests, maybe they're running smoke, tests or or some other tests, whatever makes sense for you uh depending on you know the size and time that's available, but unit tests are usually a good way to go, and then, if that passes, that's going to move to the tested environment where uh qa is performed, you know, checks are made and then here's the part that you wait for approval.

A

If everything is good, then it's going to move forward to production.

A

And there are different uh deployment strategies, so here are some of the deployment strategies. You have uh blue green, where you have uh two different versions, so version b is released alongside version a and then the traffic is uh switched to version v. And then you have a b testing where you have. A version b is released to a subset of users under a specific condition, and then we have the recreate deployment strategy.

A

Where version a is terminated, then version b is rolled out, and then we have the atomic version atomic deployment where we basically uh deploy uh by assembling. This is actually really helpful if your application is huge and has a lot of files where you copy. You know uh at the new version of an app into a different, a separate directory or location, and then once that's done once that's ready, you provision everything ready to be uh served to the user.

A

Then you switch the sim link and then you you, you publish uh that version and no one rarely notices. It's called zero downtime zero downtime deployments for a reason, because you're meant to basically publish a new version of the app without you know. Taking down the whole instance the whole website, and then we have canary deployments where new features are rolled out to selected, select users, and then we have shadow deployments which are similar, which is similar to the atomic deployments because deployments happen, but no one really knows right.

A

We have two production servers and then we test we see if there are any issues you know version b receives real world traffic alongside version a and doesn't impact anything because no one knows what's going on. That's that's the shadow part of the deployment.

A

So here's here's why you should use it. You know you want to move fast, but you don't want to break any, but you you want minimal issues. uh It's it's not it's hard to say that you know move into uh devops move into. Excuse me, cicd is error-prone. There will always be errors. There will always be issues, it's almost unavoidable, but moving to ci cd helps you avoid these issues.

A

I didn't really get into devops and that was on purpose. There was a presentation that was given about two weeks ago by uh stephen tarana who's, also at booze on devops and that's you know. I highly recommend you watch that, but I can't I couldn't talk about cicd without mentioning a little bit of devops.

A

So it's important that you automate your workflow automate uh your code. When you push code, make sure you know it always gets tested. If you know, I think one one ticket with one huge takeaway is always test your code test before you push to production.

A

If you don't test, then you're going to have lots of issues when you deploy to different well, hopefully different environments, and then you, hopefully you can catch them before it goes to production, but if you're doing continuous deployment, then good luck, because you know you're, probably going to deploy lots of bugs and then you're going to go down and have lots of problems so yeah deploy, deploy to multiple environments to help limit those issues, and this just basically allows you to you know developers to focus on development. That's what developers should do.

A

They shouldn't have to worry about uh systems so yeah.

A

If there are any questions, feel free to ask them in the.

A