Continuous integration is the first step toward a completely automated development, deployment and operations pipeline. It helps to mitigate integration issues, and catch known issues early via automated testing. If you're new to continuous integration, this course is a great place to start. We'll explore the various tools, technologies, and vocabularies surrounding the continuous integration ecosystem, as well as introduce you to the key tools of the trade that will enable you to get a headstart in your burgeoning DevOps career.
You will gain the following skills by completing this course:
- How to set up your development environment
- How version control works
- How to begin implementing testing in your environment
- The why and how of database schema migrations
- What Jenkins is and why you should care
You should take this course if you are:
- A newcomer to the DevOps or cloud world
- Looking to upgrade your skills from a conventional software development career
This Course Includes
- Expert-guided lectures about continuous integration
- 57 minutes of high-definition video
- Solid foundational knowledge for your explorations into DevOps
What You'll Learn
|Video Lecture||What You'll Learn|
|What Is CI?||What continuous integration is and why it matters.|
Creating a Development Environment
|How to set up your development environment.|
|Version Control||How version control interacts with the CI process.|
|Testing||How to mechanize your testing with CI.|
|Database Schema Changes||How to implement and run database schema changes.|
|Introduction to Jenkins||An overview of Jenkins and how to utilize it within your CI process.|
If you have thoughts or suggestions for this course, please contact Cloud Academy at email@example.com.
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.
Ben Lambert is a software engineer and was previously the lead author for DevOps and Microsoft Azure training content at Cloud Academy. His courses and learning paths covered Cloud Ecosystem technologies such as DC/OS, configuration management tools, and containers. As a software engineer, Ben’s experience includes building highly available web and mobile apps. When he’s not building software, he’s hiking, camping, or creating video games.