Articles - Étudiants SUPINFO
When a project is starting to get big, one may have encountered this
highly annoying situation where building, testing and deploying your
application takes more time that really developing it. To facilitate
all these processes, continuous integration comes to help. By
automatizing and using tools to connect the code to the processes,
it allows to save time and produce robust project with a fine
control over quality.
Building is the first task that will be automatized, there is nothing more wastfull than opening your terminal, writting your build command and running it. Moreover, some project need a quite long build command to link libraries and part of the project together. That's why make file exists, it run a series of command to build the application. Having a proper make file is an essential part of a project and often you don't even have to write one, your favorite IDE may come with some tools that already do it for you, which is always welcome.
When you need to build, you just press a button and everything get compiled with all the wonderful libraries your project include.
“Amazing” you may say. Well, keep your excitement low, we are
going to dive in developer's paradise.
Right now your project is building, and you can run it/test it
from just a keyboard shortcut, but you need to track your changes
and application versions. So, you have put a git in place. Well
done, you are on the right track to make your life a true
pleasure. If you didn't already have a git, you are a
disappointment. Git will help you track change in your code and
allow other people to work at the same time with you without
breaking your code. You need it, install it right now.
Then gitify (if that isn't a word, it should be) your project:
And make your first commit to create a checkpoint of your current
git add *
git commit -m ‘A short description will help you read your project's history'
Great, your project now has its first commit, you can keep working on your project, and once done you can do another commit.
And if you have messed up, you can go back to that commit at any time. Git offer a lot more than that, but you are surely a wise man and will be able to found documentation and read it. Git is not the topic of this article.
A git tree recreating the subway of paris https://github.com/vbarbaresi/MetroGit
Let's now come back to the building process, why you may ask? Because now, we can mark our build with a commit id, why you may ask? Because later on you will be able to see from what version of the code your executable come from. And that will surely help your future self.
One good practice is to produce executable with a name like
myproject_12345.1.exe, this show you that it's the build from commit
12345 and it's the first build.
To get your last commit hash, you can use
git log -n 1 --pretty=format:"%H"
## Unit Testing We are close to be ready, as you are an assiduous developer, you want to be sure that your code is working every time your make a change and for that, you will write unit tests. It will be a pain if you did not start your project with tests, but be brave, once you have done it you will never fear to break things or fear that your boss is going to wake you up at 2am because his application does not work anymore. Fear not, write tests.
One can also write tests before even coding, it will make his starting point, defining what functionality he should have and how. After the tests had been written, it is indeed easy to write the code, you just have to make it compliant to the test. Moreover, you will be sure that you did not miss a scenario in your code.
If you are one of my favorite people on earth (and you should) you will also be careful to cover every part of your code with tests by running coverage and see what line of code or what condition have not been tested.
You will end up with a very robust and secure project that you will have no problem ensuring to anyone that it comes 99% bugs free.
It is now time to make your first public appearance. Don't be shy, you have a project that is already rock solid and you have a great build process that will allow anyone to use your project with ease.
A git project can be sent to a server, this process is called pushing, and the remote version of your project is called a repository. Again, this article won't detail the process of pulling and pushing.
To get your project online, you will first create a repository.
Services like github or bitbucket offers some for free. Follow the
steps they give you and your project will be online in no time.
Take a break, make yourself a great cup of coffee and look at your
wonderful online repository webpage. You can see the commit with
your name and say “I did a good work” and indeed, you did. But you
feel that you are missing something and you are right, in fact the
next goal is what really make continuous integration.
Once you will push to your remote public repository, you will want
two things, to know if you messed up something, and to create a
nice build for the watchers of your project. But, instead of doing
it by hand as you are a lazy person, you just want to do your
commit for your feature, do a push request and immediatly now the
result of tests, then accept the push request and get a pretty
build. This, and much more, will be achieved by using triggers or
webhooks. We will basically let a service watch our repository and
when we will push something this service will execute an action.
One of the most known and used service is travis, it will receive
a notification of the repository website once you pushed and then
will parse and execute a file named .travis that you will have
added to your repository.
Travis page for a project
This file is a simple yaml configuration that will let you specify one or many environments to run task like your unittests or your building process.
It allows you to test your code before each pull-request's merge on divers environment to see if the new changes break things. Once the tests pass, changes can be merged, and then travis will get triggered again to build your public release for instance and then upload it to your website. Travis is highly customizable and offers a lot of options. And it's pretty damn fast at the jobs, setting up an environment and testing is often less than 10 seconds, depending of the length of your tests. You can also attach webhooks so that when travis is done, your server will retrieve the latest build and, for example, deploy it.
A successful PR with CI checks
And we are done here, relax, take a sip on your coffee, and enjoy
the pleasure of success. From now, you won't have any doubts about
conflicts when people contribute to your project, you will always
be sure that your changes won't messed up other part of your
project, your followers will always get the last version of your
application in a blink of an eye. And all of this, without
yourself leaking a sweat, all you have to do is to push a commit.
How good is that ?
And if in the future your boss argue that unit tests are a waste
of time, and that continuous integration don't bring anything,
show him how fast your application is ready to deploy, you can
(but probably shouldn't) deploy a Saturday right before leaving.
Travis will work for you and ensure everything is really fine
Have fun and code safe.