Continuous Integration

Greetings, colleagues! Tired of forcing your computer to constantly build a project? Then this article is for you! In this article I will try to briefly and clearly present the material regarding Continuous Integration (hereinafter simply CI), I will answer such simple questions as: “What is it?”, “Why?” and why?" and I will give an example of a test project. This article is intended for an experienced user who is at least familiar with Build System: Maven , knows how to use Git and knows how to push projects to GitHub ;

"What is Continuous Integration?"

Let's see what Wiki tells us about this question : Continuous integration (CI, English Continuous Integration) is a software development practice that consists of merging working copies into a common main development branch several times a day and performing frequent automated builds of the project for early detection potential defects and solutions to integration problems. Scary, isn't it? Let's try to explain this term in simple words: Continuous integration is a system for building and automated testing of software with certain configs on certain machines in order to detect bugs and incompatibilities. Okey, no problem, we figured it out, but the following logical question arises:

Why do we need CI?

Let's just imagine that you are writing a large project, and there is a need to add/change functionality. You successfully write it, write tests, launch it, and everything seems to be fine, but no. There are situations when a change in one functionality affects another, another on a third, and so on, until a bug slips somewhere and an error occurs. Yes, you can say this is most likely a poorly designed project, and you may be right, but what if it is not, and these connections really should be there? And what if you are writing and creating a project more than once, which is often the case? You ran tests on your newly written functionality, and they gave a positive result. You made a quick commit, then pushed somewhere and are already thinking about how you will smoke a cigar at home while drinking expensive whiskey, but no. Alas, your colleague, or boss, no matter who, says that because of your commit the entire build crashed. You say with bewilderment that you are a programmer, you have tested everything. But often there is simply no time to constantly test the entire project, and you only tested your piece of code to which you made changes, and not the entire assembly as a whole. This is where CI comes to our aid. With each push to any resource, CI will build your project from scratch, run ALL tests, and only if all tests pass and the project is built, the build will receive passing status . Otherwise you will have the opportunity to make a comeback and see what went wrong. So, it's time to ask the question "Why this and not otherwise?" and take a look at the software implementation. Example As I already said, the article is intended for those who are familiar with Maven and Git. Therefore, I will hope that you know how and what I do besides setting up CI, etc.

1. First, let's create a simple Maven test project and create a class in it that prints "Hello World!" and performs some simple operation, and let's write the simplest test for this class.

   As a result, we should have a primitive project structure:

   All sources will be on my GitHub. It doesn’t matter what you write in your Main and what tests there will be.

2. We push our project to GitHub.

3. Now comes the fun part. From CI, I chose Travis CI because of its availability and reliability. Travis uses GitHub to host its source code.

   So, go to the Travis CI website and log in via GitHub. In the profile we connect our project:

   Everything is ready for assembly with each push, but the question is HOW to assemble?

4. We return to our beloved IDEA and create a .travis.yml file

   This file is responsible for the Travis build config. Let's look at the most popular setting:

   • You need to specify the language in which the project is implemented;
   • Specify the path to directories to make the build faster;
   • Specify the method of notifications about successful or unsuccessful assembly.

   This is what a typical Travis config should look like:

   # https://docs.travis-ci.com/user/languages/java/
   language: java
   jdk: oraclejdk9
   
   # Improve Build Speed https://dzone.com/articles/travis-ci-tutorial-java-projects
   cache:
     directories:
     - $HOME/.m2
   
   # Notifications https://docs.travis-ci.com/user/notifications/
   notifications:
     email:
       recipients:
         - qThegamEp@gmail.com
       on_success: always # default: change
       on_failure: always # default: always

   I've added comments, with links, for clarity.

5. We push again to GitHub and open the Travis website , select the project and monitor the build. As a result, we receive a notification about a successful build:

   Also on the site we can see a badge with the successful assembly of our project, which we can insert into our README.md:

Useful links:

• My test project which you can view/download if you don’t understand something;

• Actually the Travis CI website itself ;

• Tutorial on the official website on setting up and using Travis CI;

• Good video ;

• Another tutorial ;

• Next article

There may be errors and omissions in the text. Thank you for your attention!