Continuous Integration in MyGeotab

What is Continuous Integration?

Simply put, it is a process used by developers to create, release, and maintain quality software that works properly. It is not specific to telematics software, but can be used in any kind of software development project. By continuously building, testing and deploying the software, it helps developers identify and fix problems or “bugs” as soon as possible which results in higher quality software. The main benefits are that you get feedback early and often.

Why use it?

Traditional software development happens in long development, test and release cycles. It could be years between defining what you are building and delivering the solution. This approach means mistakes get picked up late and it’s very difficult to backtrack. Engineers are not getting feedback and need to resolve issues that were created months or years ago.

In contrast, a continuous integration approach ensures that the project is always ready to use. Sometimes a new version is created, compiled, tested and deployed to the public multiple times a day. This is where the “integration” part in the name comes from. It integrates all the various steps you find in software development cycle, all the time. It has the following benefits:

• Bugs introduced by code changes can be discovered before the software is released
• The code change responsible for a bug can be identified and the responsible developer can be notified, reducing the time required to fix the bug
• Frequent feedback motivates developers to focus on making safe code changes that are thoroughly reviewed and tested

What is involved?

The continuous integration process involves multiple parts working together to accomplish the desired goals. The following are some of the primary parts of a continuous integration system.

Source Control

A source control system is responsible for managing the history of changes made to the source code of a software project. When a software developer starts working, they first “pull” a copy of the source code as it currently exists. Once the developer has implemented a new feature or fixed a bug in the existing code, the changes are then “pushed” to the source control system which stores this version of the code. When another developer wants to start working and checks out their own copy of the code, the previous developer’s new changes will now be included.

For the purposes of continuous integration, a centralized source control system is generally used. This means there is a single server that stores a primary copy of the code. All developers will pull existing code from and push new changes to this centralized copy of the code.

Build Server

A build server is the software responsible for taking the source code and “building” the code into an executable program that can be tested and deployed. The build server monitors the source control system and detects when a developer has pushed a new change to the code. It then pulls the latest copy of the code and builds a new program file that includes the latest changes.

Building the code usually means using a “compiler” to convert the human-readable code written by software developers into computer-readable instructions. The result is a new file that can be sent to users or deployed to servers and double-clicked or otherwise executed in order to accomplish the tasks that the software was designed to perform. There may also be other steps involved such as automatically generating documentation for the software.

Automated Tests

A test framework is responsible for automatically testing the software to ensure it performs the correct tasks in the expected way. A test will usually run a task with a specific set of inputs and ensure the software results in the correct outputs. For example, a test for a calculator software might validate that performing addition on the inputs 2 and 3 result in the correct output of 5.

Using an automated test framework reduces the chance that a developer’s change will cause the software to generate incorrect or unexpected results. This reduces the amount of time required to be spent on manually testing the software and reduces the chance that the software is released before a bug is discovered and fixed. For example, if a developer changes how a calculator software performs addition and introduces a bug, the test of performing addition on 2 and 3 might result in the incorrect output of 6. This allows the developer to quickly discover and fix the bug before the software is released to users.

MyGeotab uses thousands of tests. It takes just over an hour for a complete test suite to run. This will include tests on multiple browsers, such as Google Chrome, FireFox and Internet Explorer and mimics actual user actions – such as displaying a vehicle on a map or sending a text message to the driver.

Notifications

The key element of of continuous integration is quickly notifying developers when tests have failed. When all of the tests have ran and some of them have failed, the developers that recently made changes are notified by email. The email will typically include the list of tests that failed and a detailed error message about why each test failed. This information helps reduce the time it takes to determine which change broke which tests and which developer was responsible, so that they can investigate and fix the issue as soon as possible.

When the rest of the developers pull the latest copy of the code from source control, they rely on the code functioning correctly and the tests passing so they can make changes, evaluate and manually test the software without being affected by bugs caused by other developers. For this reason, pushing code that causes tests to fail must be avoided at all costs by carefully reviewing code changes and manually running tests before pushing the changes to source control. When a change does get pushed and causes tests to fail, it is then the developer’s responsibility to fix the tests as soon as possible to avoid impacting the work of other developers.

Build Publishing

The final part of the continuous integration process is publishing the results of the build and automated tests. Once the automated tests are successful, the build is made available internally to developers who can use the software and carry out any manual testing that may need to be performed.

At this point, Geotab uses these internally published builds to update an internal MyGeotab server used for testing. This test server allows not just developers but all Geotab employees to access the very latest version of the software, try the latest features and manually test that the software works correctly. Before releasing a new version, it will typically be available on the test server for a few days to allow users to find and report any serious issues that would prevent the build from being released to the public.

Once the build is considered safe to release, the new version can be released. Depending on the type of software, this might mean that the new version is made available for download to the public, or that it can be deployed to servers running the software. For MyGeotab, this means gradually rolling out the new version to our public MyGeotab servers.

Conclusion

While most users may not know much about how their software is developed, it is likely that many of the software products you have used involve some sort of continuous integration in their development process. There are many variations and the form and function of the source control, build server, test framework and build publishing of each software project may vary. The results, however, are the same: higher quality software that reaches the user with fewer bugs.