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.