What is Continuous Integration?
Continuous Integration or CI is a software development approach, which allows for the development of new and existing products.
Why is it important to us
Our software products must be continually adapted to new market necessities and technologies. Therefore, the new functionalities, data and corrections must be delivered quickly. That is why more developers work together in the same features.
We also do not want to create new errors when adding something new to the software or by correcting an existing feature. Especially we want our colleagues to continue their work.
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 feature by adding some new lines of code. He even covers the new solution with unit tests, documents and tests everything.
The 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 does not say anything.
The problem? Maybe the code changes were not covered by Unit Tests. Probably the code from A must 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 do 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 covered automatically. We ensure that every feature is completely covered with unit tests. If a new bug appears, so we cover the case with a new unit test. We even measure the code for how much our code is tested with this approach.
Branching strategy
We define a branching strategy where we just integrate new work after it is revised and tested. There are a variety of methods 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:
- https://docs.microsoft.com/en-us/vsts/tfvc/branching-strategies-with-tfvc?view=vsts
- https://www.infoq.com/articles/agile-version-control
VSTS and Build Server
We have automated our Build Server to compile and check all units in an isolated environment (so 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 responsible for finding a solution for it.
Additionally, we check the Code of Redundancy, Naming Convention, Inline Documentation and other relevant aspects. This code is used to improve our code.
You can read more about our experience with VSTS here .
Pull requests and pair programming
In a different way depending on the project and the experience of the developers. This is partly due to the fact that it is accepted, the code is part of the product.
Pair programming techniques are particularly relevant to spread the knowledge in your team, while it is a good way to identify errors (4 eyes see more than 2)
METs Score Rating cialis prices in blood flow through the cavernous and helicine arteries..
. Some of us think it is a waste of resources but we consider it a good investment in the quality of our software.
testers
Finally, there is some acceptance and integration tests. For example, being sure that the acceptance criteria are met.
Iterations in the Backlog.
Deploying our products for the Product Owners and the testers depends on the Continuous Integration, which is particularly relevant in “Continuous Deployment”. We want to cover this topic in a future blog entry.
