Welcome back to Introduction to Continuous Integration. I'm Ben Lambert, and I'll be your instructor for this lecture.

By the end of this lecture you'll know what continuous integration is and why it's an important first step towards continuous delivery, and continuous deployment.

Continuous integration is a practice supported by people and software. The practice is for developers to continuously integrate their code changes, with the current code in source control.

Imagine you, and nine other people were told that you'll be writing a book together. So, you settle on a topic, and you discuss who's going to write what, and then you go off to write. What do you think the odds are, that the final story will come together seamlessly? I'd guess pretty low.
Though, if throughout the day, all the writers shared what they're working on, everyone would be able to make minor adjustments to their writing, so that everything stays consistent. Now, that's not a perfect analogy, but it's pretty close to what continuous integration tries to solve for developers.

The longer developers wait to integrate their code changes, the more likely they are to run into integration problems. If they wait until the end of the project to integrate their changes, then it can add a lot of additional effort in the form of rework.

However, if developers continuously integrate their code, they can catch integration problems early, and resolve them as they go. This helps to ensure that code is always left in a runnable state.

How does committing code to a shared repository more often, solve this problem? Really, it doesn't. Part of the continuous integration process is to build and test, each commit, to verify that everything is working correctly.

It's that building and testing, that really makes continuous integration valuable. The workflow is something like this. A developer checks out the latest code from version control and makes some changes on their computer. Then they run the unit test locally, to verify their work, and make sure that their changes didn't break anything.
Once all the tests are successful, they can commit their code back to version control. At this point, an automated process usually a continuous integration server, will grab those changes, build the project, and run the test.

At a minimum, it will run the unit tests. Whatever the outcome of the build, the CI server should notify the developers. If there were failed tests, they can resolve the problem right away. Having these tests run on each commit, allows you to verify that the code is one step closer to being validated as production quality code.

There are a lot of other tests that are worth running before code is ready to be deployed in a production. Some are worth running as part of the continuous integration process, and others will be part of the continuous delivery pipeline. Running Linters, and basic security audits from the continuous integration process, has a lot of value, and we'll show this in later lectures.

When the continuous integration server has tested the code from developers, and the code passes all of the tests, then it should bundle up the code so that it can be used in the continuous delivery pipeline. The continuous integration process is an important first step, before we get to the continuous delivery process, because it tries to make sure that the code that the continuous delivery server uses, is as good as possible.

It's worth reiterating, that continuous integration is a process, and it's supported by people and software. Now, the reason it's a process, is all the developers have to agree to integrate their code regularly. It's only continuous integration, if developers are continuously integrating their code. If not all developers are, then it's frequent integration, or occasional integration, but not continuous integration.

In the following lecture, we'll take a slight detour to discuss how to make your development environment mirror production. Okay, let's get started.