Introducing DevOps Core Principles

0:00[AUDIO LOGO]

0:05Welcome to the AZ-400 certification playlist

0:09here at CBT Nuggets.

0:10My name is Knox Hutchinson, and I

0:13will be your instructor on this journey.

0:15DevOps, is a tremendous phenomenon.

0:19It's been going on for about a decade now,

0:22and one of the cool things about it

0:24is that DevOps itself is continuing to get

0:27better and better and better.

0:29Which is interesting because that's the point of DevOps,

0:33it's to make your actual code shipment and operations

0:38deployments, all go better and better and better.

0:41So in that way, in the sense that DevOps

0:43keeps getting better, and we keep getting better

0:47because we're using DevOps, it's a cycle, it's a circle,

0:51and you're going to see cycles and circles

0:53a whole lot in this particular set of videos.

0:57It's all about understanding why do we need DevOps?

1:00Why do we care?

1:02What even is DevOps?

1:03And what makes up DevOps?

1:05These are really important, fundamental things

1:07to understand before we start jumping into portals

1:10and clicking around and hacking away at things.

1:13So in this set of videos, we're going

1:14to talk about the core principles of DevOps

1:17and how DevOps is all about striving

1:22for continual improvement in faster deployment times,

1:26and more secure code.

1:27We'll even talk about management styles that really

1:30facilitate a DevOps lifestyle.

1:33So get ready as we start to explore more

1:36about what DevOps is that it sets up

1:39an introduction for the AZ-400 certification exam.

1:42Let's go.

0:00[AUDIO LOGO]

0:05So what really is DevOps?

0:08Of course, there is a technical definition for what DevOps is.

0:12But really the question we should

0:13be asking is, why DevOps?

0:16What does DevOps seek to accomplish?

0:19And why are organizations embracing it, especially ones

0:23that develop software in-house?

0:25That's what this video is going to cover.

0:27Let's start to introduce the core principles of DevOps.

0:31So I want you to take a moment to define

0:34what you think DevOps is.

0:37What is DevOps?

0:42Me personally when I look at this,

0:44I'm like, well, let's just take it at the simplest level.

0:46I see dev, and I see ops.

0:49So it must be something like the Fusion of my development

0:55lifecycle in conjunction with my businesses' operations.

1:00A lot of times, people also make ops synonymous

1:05with infrastructure.

1:06Put another way, that's things like networking and server,

1:10server development.

1:11And that's true.

1:12I would say that infrastructure is part

1:15of your businesses' operations.

1:17But there's also things like analytics.

1:20Your business intelligence team are

1:22part of the businesses' operations

1:24because they steer the direction that you're going with.

1:27Even things like accounting could

1:28be part-- considered part of your actual operations.

1:33So when I look at the surface level, I'm thinking,

1:36OK, well it must be the fusing of my businesses' operations

1:41directly with my software development lifecycle.

1:44And that's pretty true.

1:46The idea with software development

1:49now isn't to go out and create the world's greatest

1:52application, because people want to buy the world's greatest

1:55application.

1:56No.

1:56Instead software and development is now

1:59seen as a tool in every single business

2:04that we can develop to make the business better.

2:07If you think about tools, in general, you always

2:10want to use the right tool for the job, right?

2:12If I'm trying to get a nail in the wall,

2:14I want to use a hammer.

2:16If I'm trying to turn a Philips head screw,

2:19I'm going to use a Phillips head screwdriver.

2:21Well, with software and businesses,

2:24business' needs are complex.

2:26Therefore, we have to create software

2:29to solve our businesses' problems.

2:32So we have to look at what operations

2:35our business' needs help with in the first place.

2:39So oftentimes, we see DevOps as this never

2:43ending cycle of development, of software development, where

2:47it's we're developing software that is constantly

2:51being iterated on and improved.

2:53And we will never be able to say that we're truly done.

2:56This is actually an important like psychological thing

3:00to wrap your head around as a software developer is

3:03that the very essence of DevOps and the very essence

3:07of a business is that they live on eternally.

3:10So your work will never ever be done.

3:13But what we can do is we can break the work down

3:16into smaller pieces.

3:18So when we start to think about what it is that we need to do,

3:22we start to plan out what it is that we want to build.

3:26And why we need to build it.

3:27Why is it important?

3:30We will then go into a phase where we build it.

3:34That's kind of the idea.

3:36And once it's built, this is going

3:38to be in like a local environment or a dev

3:40environment.

3:40This isn't going to be shipped to production yet.

3:42Then we move on to continuous integration.

3:47That means this is where we start

3:49to integrate what we've build into our current code base,

3:54and see that it's going to work OK side-by-side.

3:58Once we know that it's going to work OK,

4:01we move on to deployment, where we actually

4:05see it is now in production, and it

4:08has been moved smoothly into the production environment.

4:11Then we operate, which means we monitor or maintain

4:17the application itself.

4:19And once it's been operating-- it's operational,

4:22and it's maintained, what starts the loop all over again?

4:26I'm kind of going to jump over here for a second.

4:29That's feedback.

4:32We receive feedback for the work we did.

4:34And then we get to plan what the next thing is

4:39that we want to do.

4:41This is a really big thing to wrap your head around.

4:44And this really is the core of DevOps.

4:48It really is it.

4:50It's this whole figure process here,

4:52where we plan our work, then we build it locally,

4:56then we ship the code, then it gets deployed in production,

4:59then we maintain the code and operate it

5:02and see how it's going, and then we receive feedback so

5:06that we know what to do next.

5:08And a really important part about this entire process right

5:12here is to do things in small increments,

5:17or do it incrementally.

5:19That way, we can ship small pieces at a time,

5:22get feedback, and learn how to adjust it.

5:26We call this the cycle.

5:28What a clever name, right?

5:30And this software development lifecycle

5:33is oftentimes likened to something called the OODA loop.

5:36I brought up Wikipedia here because the OODA loop

5:39is really well-known.

5:41There's a lot of history here that's actually really cool.

5:44The OODA loop was originally designed

5:47for like fighter pilots.

5:48You can kind of see the section right here,

5:50so that they could very quickly react to very bad situations,

5:56and learn how they should handle these situations before they

6:00get shot out of the sky.

6:01In the OODA loop, I'm going to write OODA right here, what we

6:05have here is we have observed--

6:07that's what we're trying to do.

6:09We're going to observe the environment that we're

6:11working in as we walk through the figure 8

6:14that we just covered here.

6:17This figure 8 here represents one life cycle

6:22of a bit of software that we've just gone through.

6:24So we're observing what is happening in the business.

6:27Then we orient ourselves around what

6:31it is that we're trying to accomplish.

6:33We then decide what we need to do.

6:37And then we act.

6:40So in observation, we're looking at business needs.

6:44We're responding to the market events.

6:47We're responding to customer feedback or internal feedback.

6:51In orientation, we're trying to figure out

6:53what are the possible solutions to all of these events?

6:56And what are the things that we could even

6:59do in the first place to solve any of the problems

7:02that we're having?

7:03In decide, we decide what it is that we're going

7:06to commit our time to doing.

7:08And then in act, we go forth and we conquer.

7:12And this OODA cycle is really, really, really important.

7:17And you oftentimes want to make your decisions with a couple

7:22of different factors.

7:24You have a quantitative factor, meaning

7:28there is some measure or some statistic that we are tracking.

7:33We are collecting data on how each one of these life cycles

7:38is going.

7:39There's also a qualitative factor,

7:43meaning we are receiving somebody's opinion

7:46whenever we actually deploy these items here.

7:50So this all comes down to what objectives

7:52you're trying to meet.

7:54Is the key objective here to increase shipment time?

7:59The time it takes to deliver our code

8:02or even deliver a product out there in the real world?

8:05Or is it more of an aesthetic thing,

8:07where we want to make people really,

8:09really happy to use our product?

8:10These are the types of feedbacks that we're

8:13going to be monitoring as we go through our OODA.

8:18Now the next big thing that you need to understand

8:21is, what are the possible outcomes, or really,

8:24what happens in our feedback phase?

8:27That's going to be a really important thing

8:29to wrap your head around.

8:30At the end of the day, Microsoft likes

8:32to tell us that there are three outcomes that there could be.

8:36The outcome could be mission accomplished.

8:39It was good.

8:40We actually learned from what it was that we actually

8:46shipped and deployed.

8:47The outcome met our objective.

8:49And the outcome was really, really good.

8:52Otherwise, we have mission failure.

8:55The outcome was not achieved.

8:57This was a bad outcome from the shipment that we've done,

9:00or there is no change at all.

9:04The outcome didn't really go in either direction.

9:08It was neither good nor bad.

9:10And part of the things that you want

9:12to do in your DevOps lifecycle when we're actually learning

9:15about how we can streamline shipping code quickly

9:18as possible is whenever there is a mission accomplishment,

9:23we want to do more of those types of things.

9:26And whenever there's a failure, there's

9:28this awesome term that's out there, we want to fail fast.

9:33A nice way of putting this is we want to get back on our feet

9:36and recover as quickly as possible.

9:38We want to say that didn't work.

9:39We're going to do the opposite of that next time.

9:41We're going to do the thing that absolutely does work.

9:44We're going to learn from this and improve

9:46upon it on the next time.

9:49The ultimate goal here is that when

9:51we deploy small increments of code and we receive feedback,

9:56and we learn from this quantitative or qualitative

9:59feedback, and we assess whether the mission was accomplished

10:02or a failure or there was no change at all,

10:05we want to ship another one quicker next time.

10:09And we want to lean into the ones

10:11where there are accomplishments.

10:13The goal is always to have quicker deployments

10:17in shipments of things that are working well,

10:21of things that are going well, whenever we

10:23have a mission accomplishment.

10:26So when we're developing our own code in-house,

10:29when we're developing our own software in-house,

10:33we want to understand, first of all, that we will never

10:35be done doing it.

10:37So what we're going to do is we're just

10:39going to build it one small piece at a time.

10:42We're going to ship it and streamline the deployment of it

10:46in such a way that it integrates smoothly into the production

10:50environment.

10:51And then we will assess based on the feedback

10:54if that shipment of that small integral piece was really,

10:58really working.

10:59Then we kind of fork our direction

11:03based on the results that we're receiving, if the mission was

11:07accomplished or not from there.

11:09So now that we understand kind of what DevOps is seeking

11:13to do, in the next video, we're going

11:15to talk about methods of getting there.

11:17And some of the tools that we can use to get there.

11:20In particular, I'm going to be focusing in on this section

11:25that we were talking about here, and that

11:27was continuous integration and continuous deployment.

11:30For now, this introduces what DevOps is.

11:33I hope this has been informative for you.

11:35And I'd like to thank you for viewing.

0:06One of the things that makes DevOps DevOps is CI/CD.

0:10Now that stands for continuous integration

0:13and continuous development.

0:15While oftentimes, these are written out as CI/CD,

0:19and it makes you think it's one thing, it's really not.

0:22It's two separate things.

0:23Continuous integration is different

0:26from continuous deployment.

0:27And in this video, we're going to set out

0:29to demystify what CI/CD is.

0:32Let's go.

0:33So I mentioned this before, and I'm going to say it again.

0:36We see all the time.

0:38We see it written out as CICD, or sometimes CI/CD.

0:44But it's very important to wrap your head

0:46around the simple concept that these two things,

0:49while oftentimes they're done at the same time,

0:53they are not the same thing.

0:55First, let's unpack what continuous integration,

1:00or the CI portion, really is.

1:03When we have continuous integration,

1:06what are we really talking about?

1:08Well, we have a really big application, or maybe

1:13our really big application, in actuality,

1:17there's a bunch of small applications

1:20that work together.

1:22That's really what we're looking at right here

1:24is, in most modern enterprise architectures,

1:28it's really something like this now.

1:30The cloud really brought this along, where we have what

1:35looks like one big application, but it's actually a bunch

1:37of really small applications.

1:39A great example of this is something like amazon.com.

1:43To the end user, looks like one website.

1:46Under the hood, it's really a ton of back end applications

1:50that are all working together to make your shopping and checkout

1:53and shipping experience as smooth as possible.

1:57So when we want to roll out new features--

2:01let's call this feature--

2:04I'll give this a name.

2:05We'll call this Feature 1A, something really simple

2:08like that--

2:09what Feature 1A is going to do is

2:11it's going to enhance our application.

2:14But we need to figure out, first of all, if that's

2:17going to break anything.

2:18That's a really important thing to understand.

2:21So what feature 1A, what we're doing here

2:24is we write the code for Feature 1A

2:28separately from any running application

2:32that we have right now.

2:33So what they actually call this is branching.

2:37Usually, that's what we're talking about here.

2:39We've basically taken a copy of our current code

2:42and are editing it in a safe, nonproduction environment.

2:48So when we want to start to perform integration, what we're

2:52really talking about is merging our feature code

2:58into an existing branch of the application.

3:02We're merging the code into an existing running production

3:08or running environment, whether it's production, development,

3:11or test environment.

3:12Now 99.9% of the time, that's exactly what's going to happen.

3:17We're going to very carefully increment our way

3:21into the actual environment.

3:23So continuous integration is really

3:26focused in on getting the code starting to merge in,

3:31starting probably with a dev environment,

3:34then moving to a test environment,

3:37before we finally get it into a production environment.

3:41You may be thinking to yourself, well,

3:44how is that, at that point, how has it not been delivered?

3:48The simplest way to put that is it

3:50simply hasn't been turned on yet.

3:53If we are shipping code that only impacts,

3:56let's say, this tiny little application right here,

3:59we may not be telling the other applications,

4:02go look at that new code.

4:04It's very simple in that regard that we just simply

4:07haven't told the rest of the environment that

4:09has been a change.

4:11This is where continuous delivery really

4:14comes into play.

4:15This is where we're basically turning everything on.

4:19This is where we deliver the software solution to a test

4:23or production environment.

4:26Or, put another way, we're delivering this new feature

4:30to the end user who's actually going to use it.

4:33And a big part of all of this process

4:36is the fact that, at each stage, at each step

4:39of the way, if we're starting off with continuous integration

4:43into the dev environment, we can review how well did that go?

4:48We get feedback at that point.

4:50Then, we move it into the test environment.

4:52Guess what?

4:53We get feedback again, and we can iterate on this process

4:56as it goes along-- guess what-- production environment.

4:59We can get feedback as to how that integration went.

5:02Then, when it comes time for actual deployment,

5:05we can yet again deploy it to the dev environment.

5:09Did it go well?

5:10Great.

5:11Let's get some feedback about how that went.

5:14Did it break anything else?

5:16Should we improve upon the actual deployment of itself?

5:19Then, we move it down to the test environment.

5:22And, finally, when we're ready to turn it on,

5:24we move it into the production environment.

5:27The continuous integration and continuous deployment pipeline

5:32has really given us a bunch of different things.

5:35The first one is, effectively, if this is done right,

5:39we can do things with no downtime

5:42because we've been testing it the whole way,

5:45through dev and test and production

5:47and iterating on it, until it's actually

5:50ready for the actual deployment to the production

5:52pipeline itself.

5:54This is why you see applications,

5:57like Amazon, that are improving all of the time--

6:00rolling out new UIs, new features, new buttons.

6:04But you never actually see those apps go down, do you?

6:07That's because they're going through a CI/CD pipeline

6:11so that the code can merge straight into production

6:15in a smooth, secure way, without any issues,

6:19because all of those issues had been handled up

6:22until that point.

6:24So what kinds of CI/CD pipelines are you

6:26going to learn about in this particular course?

6:29You're, of course, going to learn about GitHub and Azure

6:34DevOps.

6:34In particular, GitHub has a pipeline called Actions,

6:39and in Azure DevOps, they're very cleverly called Pipelines.

6:44But you see pipelines everywhere nowadays,

6:47even outside of DevOps tools like these.

6:49You see pipelines in Power BI services

6:53that are out there now.

6:54You see pipelines and some open source software operations.

6:58You see pipelines in Azure development resources,

7:03like Azure app services, with their deployment slots.

7:06There's a lot of different ways that pipelines are coming up.

7:09So, with that being said, this introduces CI/CD.

7:14CI is all about merging the code in to the existing environments

7:19to find, at an early stage, any bugs or defects

7:23in the code or the actual deployment process itself.

7:26That way, we don't take down the application and production.

7:30Once we know it's looking good, we

7:32move on to continuous deployment,

7:34where we can get the feature and the code push

7:38to a production environment where

7:40it's usable by the end user.

7:42The feature is now live.

7:43I hope this has been informative for you,

7:45and I'd like to thank you for viewing.

0:00[AUDIO LOGO]

0:06So DevOps is an entirely different style

0:09of doing your work and shipping your code.

0:12But with that comes an entirely different style

0:15of management that the organization should actually

0:18employ to facilitate a DevOps work style.

0:23And the one that many organizations

0:25have gravitated to is Agile.

0:28Now, agile is a very large and complicated thing.

0:32There's certification exams around just

0:34being an Agile member.

0:36And we have content here on CBT Nuggets that

0:38goes deep into how Agile works.

0:40And I'd really encourage you to watch that if you're

0:44serious about working in a DevOps environment,

0:46because that will help you understand the management

0:49styles that you're going to work with.

0:51That being said, we're going to take a little bit of a crash

0:53course as to how Agile can be used to facilitate DevOps work

0:58styles.

0:59Let's go.

1:00So how do we keep on track with all of these iterations

1:04and changes and deployments?

1:06Really, that is what gave birth to the Agile management system.

1:12Agile, at the end of the day, really

1:15tries to do one important thing--

1:19deliver value.

1:21Important term there-- deliver value

1:24as quickly as possible while reducing the headaches.

1:28Notice I didn't say deliver software,

1:32because it's not shipping full-blown applications

1:36that we're trying to do.

1:37No, we're trying to iterate on the software

1:40that we've already created.

1:42Now sure, sometimes there's going

1:43to be a greenfield deployment where we're developing

1:46something from scratch.

1:47But usually, what we're trying to do

1:49is build one gigantic application.

1:51And if this little portion right here could be better this week,

1:56maybe that's our mission for this week.

1:58We can add value to the organization

2:02by working on this little piece and getting it operating

2:05a little bit better this week.

2:07Now, Agile is a management style or, really,

2:11a management principle, at the end of the day.

2:15Instead of working on something for months or even years,

2:21instead, what we're trying to do is

2:23we're simply trying to break down

2:25our task into small, digestible tasks

2:29that we can deliver very quickly.

2:31I know that may seem silly.

2:33It may seem like, well, the only thing

2:35that I could get done this week is

2:36something that's really easy.

2:38Well, yeah, that's kind of the goal.

2:40We've got a team, a group of people here.

2:43And what we can do is we can just

2:45look at what can each individual person accomplish

2:49this week that could possibly add value

2:52to our overall mission statement here.

2:55And usually, that small piece is just

2:58as digestible or small as you're thinking of.

3:02It's kind of like you the learner here at CBT Nuggets.

3:06You're going for the AZ-400 certification exam, right?

3:10So you download the entire blueprint.

3:14And in that blueprint, you've got modules or domains.

3:18And inside those modules or domains

3:20are all of these bullet points of things

3:22that you have to learn.

3:23And inside those bullet points, there's--

3:25accomplish task A and task B by doing

3:28task C, or something like that, one of those individual bullet

3:31points.

3:32What if I told you that, yeah, your end objective is

3:36the AZ-400 certification exam.

3:38And you're going to get there at some point.

3:41But for this week, let's just focus

3:43on task C, just this week, or maybe even just

3:47the next few days.

3:49Just focus on task C. And if you accomplish task C, great.

3:54Next week, we'll move on to task B.

3:56And then next week, we'll move on

3:57to task A. And then after three weeks, oh, look at that,

4:00we've done this line.

4:03And eventually, at some point, you

4:06will have gotten acclimated to all of the stuff

4:09that you need to know for the AZ-400 certification exam.

4:13That's the point of Agile.

4:15It is a bit of a mental shift to stop thinking so big

4:19and to stop looking at the goal of the AZ-400 and start

4:25thinking about, well, my goal this week

4:26is really just this bullet point.

4:29And that's what Agile is trying to do.

4:32So when we are working on software

4:35and we've got this process right here

4:37and it felt really big, well, now,

4:39what if my goal for this week was just

4:42to enhance this little corner of the application?

4:45Well, guess what, that falls into my life cycle.

4:48I can plan for it.

4:50I can build it.

4:51I can move it into CI.

4:52I can move it into CD.

4:54I can operate it.

4:55And then I can get feedback as to how it went.

4:57Did it go well?

4:58Yeah.

4:59Let's see what we can do next week that's on the same vein,

5:02and then the next week that's on the same vein,

5:04and then the next week that's on the same vein.

5:06And if any of those didn't go well,

5:07we look at what went wrong.

5:09And how do we improve upon it?

5:10Let's fail fast.

5:13But the interesting thing about Agile

5:15is that Agile isn't just one method of doing it.

5:19In fact, Agile often goes hand in hand

5:22with a management technique called scrum.

5:25Now, scrum is a much more rigidly

5:29defined version of how your Agile management

5:33style should work.

5:34For instance, we define work in sprints.

5:39A sprint is oftentimes goes hand in hand with a calendar week,

5:44usually one week.

5:46Sometimes it can be more.

5:47Sometimes it can be two weeks.

5:48Or sometimes it can be less.

5:50But in this case, we're saying we're

5:51going to start the week off with a sprint that's

5:54going to be one week long.

5:56You have a stand-up meeting where everybody on the scrum

6:01team gets together, and they determine, what are we going

6:04to do for this particular week?

6:06What business objective is it going to accomplish?

6:09The scrum team has carefully defined roles.

6:14We have a scrum master.

6:17What a cool name, right?

6:19Then we have a scrum product owner.

6:23This is the person who actually has

6:25some say into why we're doing what we're doing.

6:28What is the actual business need?

6:30And then we actually have the scrum dev team.

6:34They are the people who get stuff done.

6:38It's kind of interesting how rigid scrum actually is.

6:42In a scrum outline like this, we even

6:46define things like the dev team will have no more

6:49than seven people on it.

6:50The product owner will be two people.

6:52The scrum master will be one.

6:54And the scrum master is enforcing the rules of scrum

6:59and adhering to scrum best practices throughout the rest

7:03of the team.

7:04It's really that rigid and that serious.

7:06We even then define things like, what is

7:09going to be our work backlog?

7:12This is stuff that product owners bring to the table.

7:14These are the things that we say, we want these done.

7:18The actual end goal itself is known as the increment.

7:22This is the product that's going to be delivered

7:24at the end of the sprint.

7:27Then we actually have sprint cycles.

7:30So within this one week, what takes place?

7:33We have sprint planning.

7:36Then we have a daily scrum, where

7:39each of the members of the scrum team

7:41talk about what it is that they've done to accomplish work

7:44for the sprint backlog.

7:46Then towards the end of the scrum event,

7:49after the product is being shipped,

7:51we do a scrum review or a sprint review.

7:55And then we can even go into retroactively

7:59looking at what has happened in the actual previous scrum.

8:03How did the scrum go?

8:06So when a project is considering adopting

8:09an Agile workflow or an Agile work style

8:12but they don't have all of the experience needed

8:14to define the rules themselves, scrum is usually

8:18what they go with because scrum, even though there's

8:21a lot of moving parts, at the end of the day,

8:24it's relatively easy to understand.

8:27You have scrum team members.

8:28You have sprints.

8:30You have a workflow.

8:32And then you actually have the artifacts

8:35of the scrum themselves.

8:37So all of it actually comes together

8:39in a really seamless way.

8:41It does take a little while, maybe a quarter or two,

8:45for a team to really find that rhythm.

8:48One of the most hard things for a team that is transitioning

8:51to Agile to figure out is what is actually achievable in one

8:54week.

8:55How do we break the big work that we've

8:58used to been doing down into even smaller increments?

9:01That's what Agile is really all about.

9:04And that really is one of the hard things

9:06to wrap your head around and adjust to.

9:08But once you've got that figured out,

9:10work starts happening a lot quicker.

9:13And the cool thing about it is when the work gets broken down

9:16into smaller pieces, we can adjust and adapt

9:20to what is happening in our entire business

9:23on a week-by-week basis.

9:26We're working on something this sprint.

9:27But next week, we can work on something completely different.

9:30And that's kind of a cool thing at the end of the day.

9:33And that's how scrum really goes back to benefiting DevOps.

9:39It's all about shipping, receiving feedback,

9:42and iterating on that shipment.

9:44When we break the work down into small sprints,

9:47we can iterate as a team a lot quicker.

9:50So this is why we see Agile and scrum coming together very

9:55frequently in a DevOps environment.

9:58I hope this has been informative for you,

9:59and I'd like to thank you for viewing.

0:06At the heart of everything, with all of our code

0:09and with all of our CI/CD pipelines

0:12and with all of our DevOps work styles

0:16and lifestyles and everything, lives source control.

0:19Source control is the source of truth.

0:23And it is how we, as developers and infrastructure engineers,

0:28can all collaborate on the same thing at the same time.

0:32Now source control is, again, a major topic.

0:35And we're going to dig a lot deeper into how

0:38different kinds of source control

0:39work as we progress through this set of videos.

0:42For now, let's just implement and introduce

0:45the fundamental ideas of source control.

0:47Let's go.

0:49So what is source control?

0:51That is a big topic that, quite frankly,

0:56we're just going to introduce it in this video

0:58and then build upon it and build upon it and build upon it

1:02and build upon it throughout pretty much the entire series

1:05that we're going to be talking about,

1:06including some dedicated content on just getting familiar

1:10with one of the most important kinds of source control,

1:13and that is Git.

1:15Now you may be thinking to yourself, well,

1:17I've heard of GitHub.

1:18Is that the same thing?

1:20No, GitHub is a hub for Git.

1:25Git is what actually keeps track of all

1:29of the times our code changes.

1:32For instance, we have code that we

1:35have created that runs a production application.

1:39Git can take that code and say, all right,

1:43this is the starting point.

1:45This is going to be the production code

1:47in its current state today.

1:49Then we, the developers, can start

1:53working on, like I said before, branches.

1:56For instance, I may create a branch for a shopping cart

2:02feature.

2:03So I'll call this shop cart branch.

2:06So what does that really doing?

2:08Well, it's taking this application right here

2:12and creating a copy of all of the code

2:15and storing that code in what we call the branch.

2:19All of the developers who are associated

2:22with working on this shopping cart

2:24can then make a copy of that code

2:29right here to their local computers,

2:32like their desktops or their laptops.

2:34And they can edit that code locally on their computer.

2:39When they're ready, when they're like,

2:41OK, I think this is good to go, they

2:44can choose to then push their changes back to the branch

2:48itself.

2:49And the cool thing about Git, at this point,

2:52when it's pushing all of these changes,

2:54is first of all, every time a change gets shipped back

2:58to this particular branch, that is logged.

3:01It is effectively calling it a version.

3:04And in that version, it can track every single change

3:10that took place in that branch.

3:13So as this developer right here edits

3:15it's one line of code on their local computer,

3:18and they push it back to the branch, that

3:20push action that took place right there,

3:23it's called a commit.

3:25Every time that developer creates a commit

3:28to update this current branch with their changes, that commit

3:32is logged.

3:33And what that commit did--

3:35specifically, any lines that it deleted,

3:37any lines that it added, any new files that it added--

3:41all of that is stored in the log of that commit.

3:45So all of these developers can work on their code locally

3:50on their computer and push all of their commits back

3:54into the branch whenever they're ready.

3:57So the big thing that get does right out of the gate

3:59is managing all of these commits,

4:02logging all of these commits and tracking the differences.

4:05On top of that, it has conflict resolution.

4:10If this developer here edits line 2,030, and this developer

4:16here at it's line 2,030, and they

4:20said, this one is supposed to delete something,

4:23and this one says, no, this one's supposed

4:25to edit something, there's a mechanism built into Git for us

4:29to actually handle this conflict.

4:32We can actually manage which one should win,

4:35and we can do this in an automated fashion

4:37if that's what we want to do.

4:38That's part of the CI/CD pipeline.

4:40But we don't have to.

4:42We can manage it manually if that's what we want to do.

4:45Meanwhile, over here, we may be working on something

4:49entirely different.

4:50For instance, after someone is paid for their product,

4:53we may have to now handle shipment of the product.

4:56So we'll create a shipment branch,

4:59and an entirely different set of developers

5:02is over here working on the shipment branch.

5:07And, again, these branches, at this point in time

5:10where they live, don't impact the actual production

5:14running code at all.

5:16That's a big takeaway right here is, now, developers can work

5:20on pieces of the application.

5:22And when they're ready, they can request

5:26that this branch gets pulled into the main code

5:30and run into production.

5:32Of course, that would be handled in phases two.

5:35We could pull that code into the dev environment

5:37first, then the test environment, then

5:40the production environment, and handle

5:42the continuous integration and deployment of the code.

5:47This is all done thanks to the power of Git.

5:51Git is the open source framework that

5:53makes all of this version control and tracking possible.

5:57I didn't even go into the big stuff

5:58like handling rollbacks or reverting to previous commits

6:04if that's what we wanted to do.

6:05You can do all--

6:07Git is extremely powerful, and all

6:09of the things that I'm telling you right now

6:11are barely scratching on the surface.

6:15Now, typically, in an enterprise,

6:17this is done in a private fashion.

6:21The central repository of code is handled and held

6:25on a private server.

6:27The Git tracking mechanism is all

6:30managed on the private server that's

6:32tracking changes of all of the code

6:34and all of the branches and everything like that.

6:37But the advent of the cloud in general

6:40made moving resources into the cloud

6:43a whole heck of a lot easier.

6:45So now what we can do, instead of actually

6:47having all of our code living on a private server,

6:50we can actually put it on a cloud-hosted application.

6:55This is where GitHub starts to come into play.

6:58Let me bring it down here on the screen

7:00and clear the screen for just a second.

7:02This is my personal GitHub, github.com/dataknox.

7:06When you see these repositories here,

7:08you should think of these as individual applications,

7:12like so.

7:13If I scroll down here, we can see things

7:15like individual applications.

7:17Let's pick on shadow-drive right here.

7:19Here's all of the code that makes up shadow-drive.

7:22Now if I wanted to, I could make this a private repository,

7:29meaning only people that I grant access

7:31to can actually see the underlying code

7:35and interact with it.

7:36Instead, one of the cool things about GitHub

7:39is that almost everything I get--

7:41I say that, that's not true-- but a lot

7:43of the stuff on GitHub, where GitHub really

7:44got its notoriety, is that a lot of these repositories

7:48are public.

7:49And that oftentimes means they are open source software.

7:53So anybody around the world can come along to the code button

7:59right here and clone this code straight down

8:02to their local computer.

8:04I want to put computer right here.

8:06And they can make changes locally on this computer

8:08if they want.

8:09And when they're ready, they can go through a process--

8:13it is a process.

8:14We'll talk about that process when the time comes--

8:16of pushing their changes back into the main repository.

8:21That's what makes it open source,

8:23the fact that anybody can copy the code and work on it.

8:27And we as people, we as the human race,

8:31have all been working together to create

8:35applications and code.

8:37So, again, this is just a crash course

8:40for what source control really is.

8:42Source control, sometimes known as version control--

8:46at the end of the day, what it's really trying to do

8:48is keep track of changes that individual developers

8:52are making to a central repository of code files.

8:56And we can keep track of those changes by using Git.

9:01And we can manage how we're allowing changes

9:04to be pulled into our main code repository, as well as handling

9:08conflicts, and everything that you're going to learn

9:11about when the time comes.

9:13For now, this has just been Introducing Source Control.

9:16I hope this has been informative for you,

9:17and I'd like to thank you for viewing.

0:00[AUDIO LOGO]

0:06The thing that really made DevOps come to be DevOps,

0:09is the fact that virtualization was created.

0:13When I say virtualization, I mean every single server

0:16that we deploy now isn't a physical standalone server.

0:20Instead, we can take one big physical server

0:23and dice it up into little, bitty virtual servers.

0:27But beyond that, we even introduce

0:29something called containers.

0:31And that really is the next evolution of virtualization

0:35that's happening.

0:36The fact that we have all of these things,

0:39these virtualized virtual machines and containers

0:42that we can spin up and tear down at any moment's notice,

0:45gave us the ability to introduce infrastructure as code.

0:50Whenever developers need new servers,

0:52they can just add it to their code.

0:54And it deploys the entire environment for them.

0:57So in this video, we're going to take a careful look about how

1:00virtualization and infrastructure as code

1:04really came together to define one of the most

1:07critical parts of DevOps.

1:08Let's go.

1:10So one of the things that you find out

1:12really quickly when you start working with DevOps

1:15is that whole Ops sign.

1:17In fact, I'm going to use a better color than yellow there.

1:19It's that whole Ops sign.

1:21All of our code has to run on top of something.

1:25It has to run on top of servers, typically.

1:28Why?

1:29Because servers oftentimes have two power supplies.

1:33And those power supplies plug into two different power

1:38circuits from two different energy providers.

1:41And sometimes, they even plug into two different battery

1:44backups, like so.

1:46So if one of those goes out, they've

1:48still got power no matter what.

1:49Then in a data center, where they all run,

1:52there's two different AC units blowing cool air

1:55down on those servers.

1:57And the servers' network has two different, or maybe

1:59four different, uplink connections

2:01into the actual network backbone itself,

2:04which has two different ISPs.

2:06You get the idea.

2:07The big thing about servers is really that not only

2:10that they're very, very powerful computers,

2:13but we run them in data centers to keep them alive because we

2:17really like our applications.

2:19We're proud of our applications.

2:20And we don't want people showing up to our desk

2:23going, hey, why is the application down?

2:25So it's a really important thing to understand

2:29that every time we need to deploy our application,

2:33we're not going to drive across town to deploy, to physically

2:38install a new server.

2:40No.

2:40Instead, now, we can use software.

2:42Like what we're seeing on the screen here,

2:44VMware's ESXi, this is actually an operating system.

2:48VMware's ESXi, that gets installed on a server.

2:51So when I install VSXi on my server that you're seeing here,

2:56I now have the ability to create little mini servers

2:59all on this big, physical piece of hardware.

3:03And for all intents and purposes,

3:05these mini servers aren't like special mini servers.

3:08They believe they're full-blown servers.

3:10For instance, look at this.

3:11You see I've got FILE-NUGs selected here.

3:13If I bring up the console, FILE-NUG, look,

3:16it's Windows Server.

3:17I can log into it.

3:18And there's not a dialed-down version of Windows Server.

3:22It's just Windows Server.

3:24So I can install, really, whatever I want

3:27or create any servers that I want on this ESXi server

3:31as long as I've got enough power to do it.

3:34Now, if I look at this particular server here,

3:36I've got 28 CPUs, 288 gigs of RAM.

3:41And I've got terabytes of disk space that are available to me

3:45on this.

3:46So it's nothing for me to spin up some small domain controller

3:50servers, or SQL servers, or file share servers.

3:53I can absolutely do that with no issue here.

3:57And the even cooler thing about that is ESXi exposes an API.

4:03So if I wanted to write code that could react to my code

4:09that I'm trying to ship, for instance, maybe

4:11I'm trying to ship a new feature,

4:13but that new feature requires its own underlying servers,

4:17part of that code is I could tell this API,

4:20I'm going to need you to deploy some new servers for me.

4:24And ESXi can handle creating the new servers from a template

4:29that I wanted to actually use.

4:31That's a major, major part of DevOps

4:34is the fact that we can now tightly integrate

4:37the code that I'm shipping with the actual infrastructure

4:41that it's running here.

4:42Now, beyond that, this was the first phase

4:46of software and virtualization was

4:48that we were able to take a physical server, like I

4:51have here, and break it down into smaller pieces.

4:54But then came along this thing, you've probably heard of it,

4:58called the cloud.

4:59And the big thing about the cloud is now,

5:02we can use other people's hardware.

5:04And their hardware is a lot better than mine

5:06because they're constantly recycling it all the time.

5:09And I don't have to manage.

5:10With this ESXi server, I still have

5:13to manage this physical server.

5:15If a disk goes out, I have to fix it.

5:17But with the cloud, I don't.

5:19I can simply deploy virtual machines,

5:22like I've done right here, with a click of a button

5:25or, again, using APIs.

5:29I could tightly couple in my entire Azure environment,

5:32if that's what I wanted to do, with my code.

5:36So as I need to scale my resources for new code

5:40features, whether up, down, in, or out--

5:43we'll talk about all the differences about those--

5:45I can use APIs and code to actually define

5:50how my infrastructure should be deployed and configured.

5:55The other big benefit to the cloud

5:57is the fact that when we deploy virtual machines

6:00or other resources, we only get billed for what we use.

6:04You can see, right now, mine is actually stopped.

6:08That means I'm not being built for this virtual machine,

6:11at least not for the compute portion of it.

6:12Sure, it's taking up a little bit of storage.

6:14And I'm borrowing an IP address.

6:17But for the most part, I'm not actually

6:19racking up a bill right now because this virtual machine

6:22has been deallocated.

6:24It's not actually allocated to a physical server in Azure's data

6:29centers right now.

6:30But when I want to start it up again, I can turn it on.

6:33It'll simply spin up my virtual machine in a matter of seconds.

6:37And then I'll start incurring a bill for it.

6:39And that's actually a pretty good deal, if you ask me.

6:42The fact that I only pay for what I actually use

6:45is a big, big part of it.

6:48But then take it a bit further.

6:49If I actually start working with-- let's go back

6:52to this environment here.

6:53If I actually start developing code using something like a SQL

6:57server, like I have here--

6:59I've installed SQL server on this Windows Server machine.

7:02Now, I'm ready to say, you know what,

7:04the code changes that I made to my SQL server environment--

7:07I created a new database, added all these tables,

7:09added an index to the tables--

7:11now, I'm ready to ship that out into my production code.

7:16What are some of the issues that can start to arise?

7:18Well, I've got OS versions in the mix now.

7:22I've got SQL versions in the mix now.

7:25I've got all sorts of factors like .Net versions,

7:29and runtime versions, and, oh, wait.

7:31Now, SQL actually can work on Linux.

7:33You see what I mean?

7:34All of a sudden, these versionings

7:36that I have in my development environment

7:39might not match my test or production environment.

7:42And I can start to run into a major headache

7:45because now, I have to keep all of my virtual machines

7:49consistent from one environment to the next.

7:53And that can become a real problem.

7:55This is where containers really started to shine.

7:59Along came something called Docker.

8:01And I'm going to jump back to this code sample for a second

8:04here and jump back to my repositories.

8:06So along came something called Docker.

8:08In fact, there's a really funny meme

8:10where it's a guy who's talking to another guy

8:13and he's like, oh it doesn't work on my computer.

8:17And then the other guy says, well, it works on my computer.

8:20And then the first guy says, well,

8:21then we're going to ship your computer.

8:24That's kind of the joke that Docker is all about.

8:27Docker is where we can define our application using

8:31some basic code and ship the entire application

8:36environment along with it.

8:38That includes the operating systems--

8:41well, it's sort of like including

8:43the operating system itself.

8:46So when I install a new server, and on the server I run Linux,

8:52I can now create an application that's

8:55going to run on top of this.

8:57And I'll just tell my container, borrow your underlying Linux

9:02operating system's kernel.

9:04And that's how containers actually work.

9:07They're extremely lightweight.

9:09Or they can be extremely lightweight.

9:12And they can be deployed in a matter of seconds,

9:15because all it really does is it says, create an isolated

9:19compute environment.

9:20This container right here, for all intents and purposes,

9:24is a completely separate computing environment

9:27from the underlying operating system itself.

9:31But we're going to borrow its kernel just so that we

9:34can actually run the processes.

9:36It will get its own IP address if we want it to.

9:39We can configure things like that.

9:41We can run applications side-by-side

9:44in different containers.

9:45And that's kind of the majesty of it.

9:48We can run containers on top of virtual machines.

9:52We can spin up multiple copies of the exact same container

9:57and then load balance across it.

10:00That's really kind of the beautiful thing here.

10:02Let me show you an example of where

10:04I created a very basic container for a very similar purpose.

10:08I was using SQL as my example there.

10:11Well, check this out.

10:12I've got a SQL server container that includes the Star Wars

10:17database.

10:18Here's the T-SQL commands that can create the database.

10:20But here's the actual backup of the database itself.

10:24So if I look at my shell script here,

10:26you can see exactly what it does.

10:28It says, get the Microsoft SQL server

10:31image that's running on Ubuntu.

10:34Then deploy SQL server with these basic configurations.

10:40So it downloads the image and then runs the Docker image.

10:43So now we've got an empty SQL server

10:45that's up and running in your environment.

10:48We then use these two commands to copy the local Star Wars

10:52backup into the container, because it's

10:55an isolated environment.

10:57And then we tell the Docker command line

11:00to run these exact commands on the actual container SQL

11:07environment.

11:07You can see, it's doing restore the files

11:10and then restore the database.

11:12So this runs an isolated SQL server on Linux

11:20in an isolated environment.

11:23Outside of this container, I can open up SSMS on my computer

11:28and connect into that container.

11:30And I've got a lightweight way to explore and learn

11:34how SQL server works.

11:36So again, we're going to learn a lot more about how containers

11:40work as we progress along through this playlist.

11:42It was important to me to actually set up

11:45just at a high level what containers really do.

11:48It's all about taking everything that we

11:50need to create an application, defining its own environment,

11:56like versioning and everything like that.

11:58And all of that is contained and held inside the container.

12:02And as long as it can get access to the kernel, which

12:04it will by default, then the container can run.

12:07It can run in an environment that

12:09is different from the underlying operating systems environment.

12:13And because of that, we've gotten really good

12:16at DevOps of shipping containers and editing

12:20code within containers.

12:22So this has been introducing how containers and virtualization

12:26play a mix in DevOps.

12:27I hope this has been informative for you.

12:29And I'd like to thank you for viewing.