To watch the youtube video where I speak about this topic and demonstrate the project, click here.
What Is GitLab?
GitLab is a repository for versioning and storing code, just like Github. GitLab has some interesting features, namely continuous integration, which is what we're going to take a look at.
Why Use Continuous Integration and Continuous Deployment?
For most major code projects, there are a few things that need to be done.
1. Code must be written.
2. The code must be compiled or built into an application.
3. The code/application has to be tested. (There may be multiple phases of testing).
4. The code (if it's acceptable) must be deployed somewhere. (Either staging or production, or both.)
That may seem like an easy list, but there are a few issues:
1. Multiple people work on the same project, so one person's code may conflict with another person's (or with previous project code).
2. There are different development environments. Just because the project works on my computer, doesn't mean it works on someone elses.
3. It takes time to verify that the tests work and then someone has to push the application to where it needs to be.
These issues compound with each other, where it becomes harder and harder for huge applications with many people working on it. The way to solve this is Continuous Integration and Continuous Deployment.
What Is Continuous Integration and Continuous Deployment?
Continuous Integration is a pretty simple concept. Let's say there's a code project that we're working on, and it's stored in a code repository (like GitLab) for versioning. Any time we add/change the project code on our computer, we make a commit for that change and push it to the GitLab repository. When that happens, we're not sure if the changes conflict with anyone else's code (or some other test we may not be able to run on our computer).
What "Continuous Integration" does is that commit will trigger a build and test to be done for our project. Each commit to the repository will cause a docker image for our code to build our application and run any tests we specify. We can then be notified if our code breaks anything or if everything is fine.
This makes our personal life easier because we can commit our code and not have to do anything much to see if the project is still working, but on a larger scale, the other developers on our team can all commit their own code so we can have our project be constantly added too every single day.
"Continuous Deployment" takes it a step further and allows us to specify that, if our build and tests were successful, we can automatically have the application be pushed to where it's meant to be deployed. (Staging, a live server, etc.)
Continuous Integration and Deployment may be a bit tricky to set up, but it makes maintaining and working on projects much easier, so it's really worth it. All that needs to be done is to create a build/test environment (a docker image), as well as write the actual build/test instructions, and then specify what should be done if successful or not.
So let's get into actually using Continous Integration with GitLab.
Make A Starter Project On GitLab
We're going to be using GitLab as our code repository, and we'll be using their Continuous Integration/Deployment tools. Register for a GitLab account if you don't already have one.
Next, go to the GitLab page to create a new project. Name the project "srcmakeci" and press the Create Project button.
If you've never created SSH keys for your GitLab account, go ahead and do so now. Just follow the instructions in this tutorial. (It's a little confusing, I know. The video I have for this topic shows me doing this, so watch it if you need help.)
Create A Code Project On Your Computer, And Push It To GitLab
Our repository on GitLab is created, but we want to push an example project to it to initially set it up. Let's create it. On your computer, clone a sample C++ project that I've set up on github.
(Shout out to OlinData for actually setting this project up. Check the references at the end of this article to see the youtube video they did showing their GitLab demo.)
So our project is set up. It has one basic C++ file that prints hello world, one bash script file to act as the unit test for the C++ file, and a .gitlab-ci.yaml file to specify the continuous integration instructions. Our goal is just to set this up, so we're only going to take a brief look at it. The .gitlab-ci.yaml file has the following code inside of it:
We specify our docker image to be Ubuntu 14.04. Before we do any scripts, we need to set the image up by installing GCC to compile our C++ code. (It's the same as setting up a fresh Linux install.) We specify one command under "compile" which has a few scripts. One script to compile the C++ code, and another script to run the verify.sh file that acts as our unit test. Finally, the artifacts line will save the helloworld file so it can be used later (or downloaded from GitLab for us to view).
Using GitLab's Continuous Integration
Our code is set up, but what do we need to do to make this work on GitLab? Actually...all we need to do is push the project to GitLab. GitLab is really nice and they make it easy, they'll know that we want to use CI since we have the gitlab-ci.yml file, and they'll run our project's continuous integration commands on one of their shared "Runners". (Read the next section to learn more.)
Push the code to GitLab. (CHANGE the url to your gitlab project's url.)
Then, on the GitLab project page, go to the "CI/CD" tab and check out the "Jobs" section. You'll see the CI commands running.
And that's it. Read the logs and download the artifacts if you want.
Conclusion - What To Do Next
Okay, so our GitLab CI introduction works, but it was pretty brief. But congrats, you now know how to use Continuous Integration! For free!
There are a number of improvements that we can make, though, for real projects:
That's a lot of stuff that we have left to do, before becoming CI/CD masters! I'll be going over all of those steps (eventually) in more blog posts and youtube videos, so make sure to follow me on the various platforms I have listed below.
Again, I'd like to shout out OlinData for making a useful demo of GitLab, as well. Feel free to check their youtube video out, as they do another GitLab demo with a bit more features than what we did in this article.
Here's the video where I go over this topic and do the demo.
Like this content and want more? Feel free to look around and find another blog post that interests you. You can also contact me through one of the various social media channels.