Continuous Integration in Software Development

Continuous Integration in Software Development

What is Continuous Integration?

Continuous Integration or CI is a software development approach which allows an existing software product to be changed without unwished side effects, allowing the developers to create new functionalities and correct bugs, sharing their changes with the whole team, which will profit from it.

Why is it important to us

Our software products must be continuously adapted to new market necessities and technologies. Therefore, the new functionalities, data and corrections must be delivered quickly. That is why more developers must work together in the same features.

We also don’t wants to create new errors when adding something new to the software or by correcting an existing feature. Especially we want our other colleagues to continue their work after we make some changes in some other parts.

A small example where Continuous Integration is needed

Imagine a small team with 2 developers: developer A (a junior developer) and developer B (a senior developer).

The developer A corrects a feature by adding some new lines of code. He even covers the new solution with unit tests, documents and tests everything.

The developer B sees that a part of his code is not working anymore… Maybe a part which depends on the new change of developer A. Developer B askes the terrible question to developer A: “Have you changed something in X?”

Developer A thinks: “of course, that’s my job…” but he doesn’t say anything.

The problem? Maybe the code changes were not covered by Unit Tests. Probably the code from A should have been reviewed from B…

They could have included CI in their Build Server in order to test this feature in an isolated environment.

How we do it

Unit Tests

New unit tests are created when we create new functionalities, maybe before, while or after they are created. With the unit tests a big part of the code can be automatically covered. We ensure that every new feature is completely covered with unit tests. If a new bug appears, we also cover the case with a new unit test. We even measure the code coverage to evaluate how much our code is tested with this approach.

Branching strategy

Branching strategiesWe define a branching strategy where we just integrate new work after it is revised and tested. There are a whole variety of branches strategies used in different teams and companies which depend on factors as the size of the team, complexity of the software or features to implement, etc. Defining the best branch strategy needs some time and experience with the development team.

You can read more about it here:

VSTS and Build Server

We have automated our Build Server to compile and check all Unit Test in an isolated environment (so that no one says: “but it works on my computer!”). When the Build Server finds a problem a new Bug is opened and sent to the person who made the commit. This person is then responsible to find a solution for it.

Additionally, we measure the quality of our software every week using external tools which checks Code Redundancy, Naming Convention, Inline Documentation and other relevant aspects. This code quality measurements are used by us to improve our code.

You can read more about our experience with VSTS here.

Pull requests and pair programming

We revise the code from our colleagues in the team using the pull request system of VSTS and have adapted it in different ways depending on the project and the experience of the developers. This is partly an automatic process but the highest responsibility is now on the reviewer(-s): a high level of discipline is needed here because from the moment a pull request is accepted, the code is part of the product.

Pair programming techniques are especially relevant to spread the knowledge in your team, while it is a good way to identify errors (4 eyes see more than 2). Some can think that it is a waste of resources but we consider it a good investment in the quality of our software.



Finally, there is some acceptance and integration tests which require human work that can’t be automatized by other techniques. For example, being sure that the acceptance criteria are met.

Our software developers and the tests from our testers are taken into account and if new issues are found, which couldn’t be found during the development, the Product Owner will consider them for future Iterations in the Backlog.

Deploying our product for the Product Owner and the testers depends on the Continuous Integration, which is specially relevant in “Continuous Deployment”. We will cover this topic in a future Blog entry.

back to overview

Leave a Reply

Your email address will not be published. Required fields are marked *