News Stay informed about the latest enterprise technology news and product updates.

Need for Continuous Integration

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: