Hi folks my name is Alex Sharma
I'm a developer advocate at circle CI and I am here today to talk to you about continuous integration which is a
software development practice where everyone on the engineering team is continuously integrating these small
code changes back into the codebase. After each change that they're making,
there's a suite of tests that runs automatically that checks the code for any bugs or errors or anything like that
Cool, so what does that look like in practice?
I've drawn this beautiful flow chart up here for you.
Step one is you make it change,
and this is something maybe on Github you make a future branch you push it up submit a pull request,
that's the change that I'm talking about here, okay?
Push that up, then you run your tests automatically and that's that's pretty important
The tests need to be run in a consistent way so that everyone on your team has full confidence that
they're running the tests in the same way.
You don't really have a guarantee that your machine is the same as, you know, your neighbor's machine.
That's that's really hard to to lock down so those tests are running automatically somewhere else, if they pass,
right, they pass: you're good to go and you can just keep making changes. Right you go right back around
submit another pull request, go wild! If
the tests fail you need to make sure, it's your
responsibility to fix the code, okay? Fix the code until your tests pass, and then you can continue developing, so it's this
wonderful cycle, the idea being that you want to catch these bugs as soon as you can,
right? So, even if they're not lingering over a long period of time. So that's what continuous integration is and next time we'll talk about
Why you would be doing this?
So today, I'm going to talk about why
continuous integration is such a good thing for you. So, you might have picked this up from last time,
but it's just safer, right? The fact that you're running tests after each little bit of code means you're gonna catch bugs
before they even happen. It's kind of like Minority Report for software development. Think about it that way.
That's a movie reference. So there's fewer bugs, okay,
and then there's this wonderful
by product of doing proper continuous integration, and the by product is that it's it's hard to continuously integrate
large amounts of code, right, because there's more of a chance that you'll get a merge conflict, right?
The amount of code, if it's small, they will probably agree with each other you can integrate them,
but if it's big then you're gonna have trouble actually doing that on a regular
Frequency okay? So, you're moving faster, you're actually you're making smaller changes
but you're doing them more often, and what that leads is to more features you're actually able to make an impact faster.
You don't have to wait weeks to actually see your work out in the real world.
As long as you're doing continuous delivery, and we'll talk about that later.
The second thing is that you're making better decisions, right?
Because you get your stuff out into the world faster,
it means that you'll be able to figure out whether or not your users even like what you built.
So, you might be able to test a theory
more rapidly than you would if you were taking months, right, to build an entire release, and so that's kind of the whole idea is
that this iteration speed really increases the
quality of your code: not only is it safer, but also it better matches
what people even want because you have a better understanding of
what people are actually using, because of how quickly you're moving in these small increments. So, cool! I think that about does it.
There's a from a high level. That's kind of like continuous integration is it's so exciting and nutritious to software developers.
Look at this. I'm not even on the screen. I'm sharing my screen instead. So, today
I'm going to show you how to set up a project from Github on circle CI, and we're gonna break a test,
we're gonna see it pass and we're gonna move on with our lives.
It's gonna be great. So, the first thing that you're gonna need is a project of some kind on Github.
I've chosen, because I'm a little bit biased, Circle CI Docs.
Super creative, I know.
So, I forked circleci-docs,
and we need to clone this down.
So we'll head over here. Let's just see where we are.
Good
Then we'll clone in here, enter your password
(don't tell me what it is) ...and
wait.
Depending on your internet speed, and
I guess the project size as well. Circle CI Docs isn't a traditional web applicationm, it's just a Jekyll blog.
But, we do have tests, and that's really kind of what we need
to get this going. So the one thing I am gonna show you before we head over to
Circle CI is the config file, and
this is where all the wonderful stuff is
located. This is the single file where you will put the instructions to Circle C on I on how to run your build so you'll
Put in environment variables you'd put in steps to actually check out the code
Restore dependencies from cache if you have that you can run very specific commands
And this is really almost infinitely customizable, and we're not actually going to focus on that today
We've got plenty of documentation on how to set up
Good configuration for your projects, and we've actually got some some great boilerplates, and if you're on our
previous
version of circle style you can actually
Some of these configurations are actually inferred for you
But anyway, don't worry about that all you need to know is that this is just kind of a list of instructions
And we're gonna see the names of these steps play out
On the actual build page when we run our tests so
Let's let's add the project here. I'm in the circle CI app here
I've already signed up since I work here
But you will have to do that and you'll just have to authenticate with either github or your bitbucket account most likely
It's github if you're following
this video so I'm gonna add projects and
I want to build on Linux, so let's do that and here are my my
Repos on my account, but I want my Fork of a circle CI doc so let's hit set up project
I want to use the new platform obviously
super shiny
I don't think you need to list the language, but let's just put other because it's mostly just
Mostly just to check all things, so let's don't worry about that
So now it wants us to it's telling us create a folder named dot circle CI and add a file config
Yeah, well we already have that actually because I've worked it and we've written that for circle CI Docs
That's that's already been done for us, so we don't need to do that, so let's just start building
Right, let's just go ahead and do that and we'll save the hard work of building a configuration file for another video
I just want to show you what this actually feels like
to use circle CI
So here we have the build is running
We can see when it started so we can see how long the build is actually taking to run if you've purchased more containers
Depending on your plan you can run things in parallel, so that's kind of nice
And yeah, we have an estimation of the build time. This is really it's really a
hopeful
Stuff at the top there, so let's look at what's going on. This is all part of the test phase
We're spinning up the environment. We're checking out the code. We're storing the cache, and you should look familiar
because
These are the actual steps in the configuration files, so I didn't just lie to you when I said that
We were consuming these steps and then just performing them
So this is going to take the longest test with HTML proofer
And what this is doing it's going through and making sure all the links actually work
Which is important for a doc site?
You don't want to have broken links scattered throughout your documentation so this is our testing phase here
And so now I'm gonna just have to talk a little bit while we wait for
The tests to finish, but what we should see is that?
build passes I don't expect any sort of
Tests to be failing it actually says it's passing here, but I'm not sure whether that's inheriting the main circle CI Doc's
build
Or if it's if it's taking my fork, so we don't actually know so it looks like all the tests did pass though
we've moved past the HTML poofer phase and
Now we're uploading artifacts
So great, and I think this is just a copy of the whole site all right cool, so
Great, we're done. You can probably hear my fan going off, and I think that's because I'm recording my screen
My back is angry, so this is fixed
this is fixed because I believe it thought it was broken up until now because it's
Inheriting all the demos I did before this so we have a green build and that's excellent
But let's break it and see how that works
So say you're going along you're working on some code in this case
It's just markdown but say you say you just you removed something and you make a typo
And what we've done here is we've broken this link so
This link will no longer work because it doesn't have the rest of the domain name
Included in this link so this is an incomplete link and hopefully our tests will catch that so
We will add this change. Yep. That is what I want
We'll commit this broke a link
Whoops and
Then we'll push this
now
I'm just pushing
from master to master and
Sometimes that can be dangerous in a production environment
But a key part of continuous integration is committing and pushing everything into a mainline branch so we we have to obey that
The rules of the game, okay, so we have just pushed this up, so now what we should see
is
Or wait this is gonna be anticlimactic. We don't want to see build eight
There should be a new build starting build number nine broke a link whoops
This is gonna be really
Really exciting
Because we're gonna see the tests fail
Okay, so let's just take this time while while everything is building
to talk about why this is is so
so helpful so someone just made a change and
they
Merged it in pretty quickly right that wasn't a ton of work that we just did
But within minutes we're gonna find out that
master is broken and that's really important because
Other developers who are depending on master that relying on master to actually be correct
they won't be able to branch any new work off of a
unstable mainline branch so this is this is kind of the crux of
Why this is so helpful is you might have this tab open?
Okay, see see how we broke this link so
We we failed the tests here, and that's gonna land us with a failing build overall
So green are steps that have finished successfully read our steps that have failed
Cool, so it's failed
And now we need to do what an agent one should do in this situation which is?
fix fix the mistake fix the red-billed
So let's actually just luckily it's in my undo buffer
So I can cheat do that cool, so let's bring the base URL back
Let's add this fix the link
And
Then let's push this back up
So I know this this may be this seems kind of repetitive, but this is the workflow
And in the majority of cases this is kind of the percentage of time you'll be spending with circle CI
You can just you can see what changes actually broke
The mainline branch and you can see what brought it back to normal, and this is really important
this is the core part of continuous integration and the core part of
What circle CI does?
There's a very clear version history of one things went wrong and at what times and how long it took to build so?
Yeah, this is the takeaway
Within minutes, we knew that something was wrong and we were able to respond to it, and and that's that's kind of the nature of
the
Development animal that were wrangling here
is
That we want to catch these things before they become real problems
We want to catch these small errors before they turn into big production outages, and this is how we do it
We want to keep these times as low as possible
So there's all these other fancy ways you can increase the speed of your build and I mentioned parallelism
There's caching
There's all sorts of little tricks that you can use to make sure that the builds don't take any longer than they need to
And in fact we could probably be optimizing our own circle CI Docs
it's unclear whether we need to upload all these right like this is this is kind of a
Costly step right it takes it takes a big chunk of time
So that's another thing is that you have clarity into which steps are taking longer than others
And that can help in optimizing your build time
so
We're hoping right that this build past
And it looks like it did so we we fixed it. We brought it back to normal and
we just
connected a project from github to circle CI and
You should be very pleased except. I don't know if you were following along
Hopefully you were just forking circle CI Docs as well if you had your own web application
Then you probably got hung up this part because you don't know what to put in here necessarily
But that's another video for another day
And I hope this gave you kind of a good impression of what it's like to actually be using circle CI
Along with github they work very nicely together
And what you can actually do is get really cool buttons like those cool integrations like this I think
If I were to make a pull request you would also be able to see whether or not the build
Was passing the Associated build is passing and that's it? That's a really great tool?
for future branches and pull requests, we didn't do that in this video, but
you can kind of see how that would become a
big part of your development workflow
So the last thing we should talk about is the difference between
The three types of continuous software development processes. We've spent a lot of time on continuous integration
But these are closely related all these are very closely related
They're often confused with each other because they aren't so closely related so just a quick recap of what?
Continuous integration is all that is is a software development practice. Where you are
Continuously integrating your changes into a mainline branch
and
The whole purpose of this is to avoid conflicts it's to avoid surprises
By reducing the size of work that you're working on and then constantly merging those in with each other
Continuous delivery on the other hand is making sure that your code that mainline branch that everyone is merging to is
always in a deployable state so when
if you remember that chart that we did at the beginning of this series that
Was actually sort of a combination of continuous integration and continuous delivery I lied to you
The delivery part of the continuous delivery part is the testing part so having that suite of tests running every single time you?
Merge your code to that mainline branch
Ensures that the branch is ready to go at any point and so that's really the only difference
Is that you're making sure that your code is ready to deploy at any given point and often that means
Actually deploying your code to a production like environment, so you're not actually shipping it to real users, but you are
Mimicking the environment that will be working out of the real world
So what's the difference between continuous delivery and deployment that continuous deployment the only difference here between continuous delivery and continuous deployment is
instead of manually deciding what changes to sent out into the real world if
your code passes the tests here automatically gets deployed to users, so this is a kind of a
Risky way of doing things, but if you get to this point that means your order is truly
embracing this DevOps culture truly embracing this continuous I
guess lifestyle best
So all of this is done in an effort to reduce this feedback loop between
We want to get stuff out to users as quickly as possible so they can give us feedback on whether they like it whether they
Don't what's working what isn't?
So these can kind of be viewed as different steps
the spectrum of how continuous you actually are developing, so I hope you've enjoyed this series and
Hope you've come out a little bit more enlightened about what being continuous really is
Thanks for watching.