Continuous Integration
The problem
In software engineering, a recurrent problem has been noted in the development process. It appeared that the first 80% of the app are done quite fast, and the effort to finish the last 20% are incredibly huge, and often too huge to be finished. We have more aborted projects in software engineering than in any other domain.
The origin of the problem is some requirements that are not well specified or understood, bugs that takes too much time to be detected, so it makes it harder to correct at an advanced stage of development, code merging that cause more bugs, etc.
The main purpose of continuous integration is to avoid or reduce these negative effects.
Definition
Continuous integration (CI) is the practice of integrating code changes into the main branch of a repository frequently, and testing the changes, as early and often as possible. How to test :
- Compile the code : this is the first thing to do in order to detect mainly merge problems. This is done by implementing a job in a CI tool that will build the software automatically and regularly.
- Launch tests (unit, functional, monkey, load, security, static analysis, etc). This is done by interfacing test tools (SonarQube, Selenium, Junit, etc) with the CI tool.
History
The term “Continuous integration” first appeared in 1994 in the book Object-Oriented Analysis and Design with Applications (2nd edition)” to explain how, when developing using micro processes, “internal releases represent a sort of continuous integration of the system”. In 1997, Extreme Programming (XP) included continuous integration.
One of the first open-source CI tool, CruiseControl, was released first in 2001, and the last release was in 2010. Hudson, a CI open-source tool written in JAVA, appeared as a popular alternative and other open-source build server in 2008. In 2011, a german society that gave birth to the widespread tool Travis CI, was founded. Also in early 2011, after the announcement of Oracle to make Hudson become a commercial tool, Hudson has been forked to continue the project under the famous name of Jenkins, and their project is way more active than Hudson nowadays.
Set up
To make CI effective, developers team need to have reach a certain level of maturity. It implies at least to have a clean gitflow (an integration branch and regular merges after code reviews), and to be able to implement unit tests.
Technically, a server has to be used where you can install CI server and other testing tools, that it should be accessible for all the developers and QA team and it must have access to the version control system server (GitHub, Gitlab…). It is possible to use several slave servers to launch jobs for big teams or when several environnement are needed.
So basically, a job has three steps most of the time :
- Configuration, where you can set some parameters, and use git plugin to clone the repository you want to test.
- Build, where you launch the compilation/tests.
- Reporting, where you set how to report the result and potentially some notifications.
QA must make the developers team to get used to review reports for their own compilation or unit test job, and to fix it if necessary. Of course it takes some time at the beginning but it will be easier in the end. So we are more like the red line in the pareto graph above, we have a better global vision of the advancement of the project and have more confidence about its quality.
At Wassa, QA has made the choice to use only open-source quality softwares. We have a QA server under MAC OS where we installed Jenkins that is configured with our LDAP and updated. We installed the “Jenkins SonarQube plugin”, and configured SonarQube jobs that are linked from jenkins. We have planned SOAPUI and Postman jobs to test Web Services, Cpp Check and other report plugins for our R&D projects, Appium for functional UI tests, Dashboard plugins to have a good global view of current jobs, etc. We have a nightly build for most jobs and are likely to perform manual launch especially for confirmation tests.
Also, we work with Slack, and we added the “Jenkins Slack plugin” so every morning we have Slack notifications on our project channels about the results of nightly builds. The sooner we see the bug, the lower the cost is to fix it.
Do you want to know more about WASSA?
Wassa is an Innovative Digital Agency expert in Indoor Location and Computer Vision. Whether you are looking to help your customers to find their way in a building, enhance the user experience of your products, collect data about your customers or analyze the human traffic and behavior in a location, our Innovation Lab brings scientific expertise to design the most adapted solution to your goals.
Find us on:
· GitHub
· Our WebSite
