A brief summary of Continuous Integration

1. Continuous Integration
What is “Continuous Integration”?
The main point of CI is ensuring that you got better quality code. We have to implement
continuous processes of applying quality control in general (running the unit tests, integration
tests, end-to-end tests, performance tests, etc). This continuous application of quality control
aims to improve the quality of software, and to reduce the time taken to deliver it.
Why is it important?
It also help teams be more efficient and help them concentrate in on getting code, getting
functionality updated.
It is important to deliver software in a faster way because one of the goals is first of all get
feedback from our clients.
Also it can help the developer see very quickly if what he is doing is the correct thing and it is
working… and it is doing what is expected with the rest of the context of the system.
So you wanna try out Continuous Integration... Where do you start?
There’s a couple of principles (part of the original paper) that you ought to know:
● Have a single source code repository
● Automating your build
● Automating your testing
● Publishing the latest version of the distributable build.
● Get that build into production
We are going to try to explain every principle.
1. Have a single source code repository
In general you should store in source control everything you need to build the
application. Currently we can use source control systems like Git, TFS, etc. We
encourage the idea of collective code. We know we have very modules in a project, and
the problem occurs when one team or person become very possessive of the code and it
can cause lots of social problems within the development organization.
Many developer teams said: it is not our issue, and my job is done. But you should think
in the big picture and be proud of the whole application… this is something that doesn’t
rely on tools or technology, is a set of practices that impacts the whole ecosystem of
software development.

2. 2. Automating your build
Using an IDE is not enough for automating your build. You need to have something
repeatable, reproducible in the exact way. Every developer has its own settings on each
particular IDE… and every IDE on every developer machine is different, even they have
different versions (VS2010, VS2015, VS2019).
Situation I.
Probably in the past you received a production bug, and you were not able to replicate
the issue. In many cases the developers don’t put attention on the build script, they say:
nahhh is the build script… but they should give it a special respect and treatment.
Also, if you need to test that the production bug was fixed you need to rebuild that code
exactly as it was built.
Situation II.
It was working on my machine… so why is not working on production?
It sounds very familiar? Well, there’s an interesting rule, if I get the latest version of the
repository on a virgin machine (new machine), I should be able to build the entire
application without any issues.
3. Automating your testing
Here we are not talking only about the unit tests… we have to consider all the tests
around the application.
● Unit testing
● Performance testing
● Integration testing
● Functional testing
● Acceptance testing
Some people said that they have a “Continuous Integration” process, however they are
only running a nightly build and after four days the build is broken and nobody cares or
nobody was notified that the build was broken.
4. Publishing the latest version of the distributable build.
You need to check in at least once a day, do it regularly…
Integration is primarily about communication. Integration allows developers to tell other
developers about the changes they have made. I is a way to communicate failures,
success, metrics, etc… We can introduce some rules in the build process, for example
for performance testing… if it is more than 10% slow… or if it consumes more than
200MB of memory… then fail the build…

3. If some developer broke the build it is not the end of the world. The important thing here
is that every developer will see that the build is broken, and that there’s an issue. It is
better to have issues during the development than in production.
Also it a developer see that the build is failed, then he knows that he need to wait to
upload his code. It would be worst if he push his code because it could evolve into a big
mess and it would be harder to fix the build.
5. Get that build into production
It can be a good practice to test in a production clone, but sometimes the infrastructure
maybe expensive and that’s a big deal.
One of the most difficult parts of software development is making sure that you build the
right software. But we have to make it easy for anyone to get the latest executable,
because we want to get a fast feedback.