For starters, let us first define what is continuous integration.
According to wikipedia “Continuous integration (CI) is the practice, in
software engineering, of merging all developer working copies with a
shared mainline several times a day.”. This basically means that if
several developers are working on a product/ application , we need to
make sure that the individual changes, or the different changes, when
merged do not break at least the core functionality of the application.
As the dependency of the application you are working on grows, more is
the business risk associated if something goes wrong. Imagine one day if
Google decides not to work, most of the population would like to
believe this is the start of the apocalypse.
CI comes in here to the rescue. Here’s why you need to integrate CI into your application.
- Keeping the build stable:
How many times developers have been scanning through a series of commits
in source code, just to identify what commit broke the build. In my
experience, Nuget packages are culprits most of the time. CI Systems can
be configured to trigger off a build once any commit is checked in so
that the problem can be identified and resolved as quickly as possible.
We can also prevent the scenario in which code is working on one machine
and not the other.
- Increasing developer confidence
So, you have to change a framework level control which is called
everywhere in the application. Instead of spending hours code reviewing
it with your seniors and thinking about the possible implications of the
change, simply commit the changes and and let the automated test suite
tell you that your fix has broken any functionality or not. Although
there is now substitute for dry running the code, CI gives the developer
the confidence to make big changes and also save time testing the
features in the long run.
The overall development process speeds up and also the application is open to major changes and upgrades.
- Making code integrations easier
The scenario in which multiple teams work on an application in different
sprints simultaneously, there is a big chance that a bad code merge
goof-up things just when you are going for integration testing.
Although debatable, the policy which I like to believe is the best
policy in multiple teams , is to merge all the branches on a daily basis
into a staging branch, so that during deployment, one can simply deploy
the staging branch to production. In this scenario we can harness the
power of CI to make sure that no code changes are breaking the core
functionality of the application.
- “It works on my machine” trap
The best time to know if something is wrong is compile time. However , compliers can only cover basic code issues.
Imagine at the end of a three week sprint we end up with a very complex
and important feature breaking and no one knows why. The tests work on a
separate and independent system so that we do not fall into the “It
works on my machine” trap. The server infrastructure is closest to
mimicking production environment and the tests pass only when the CI
system clears them.
- Keeping the product up-to-date
The product owner may decide to ship the product with the new features
more frequently. This engages the end-user experience, as they don’t
have to wait for an entire life-cycle to complete.
As we ensure that the code which is going into production is relatively
bug free, updates can be sent out more quickly with more teams
simultaneously sending out their respective features.
- Use time to innovate, rather than fixing broken code.
Bugs, if introduced in the system through a feature are caught early,
just after a commit, it is easy for the developer to fix it as we can
relate it with the code causing trouble.
This gives the developer more time to research, or work on newer
features altogether thus speeding up the entire development process.
Link for Original Source: http://blogs.quovantis.com/need-for-continuous-integration/