Business requirements are rapidly changing. To stay in competition, businesses always look to data, market, trends, and so on with different perspectives and try to match with the most trending changes. Business people like to analyze things, try experimenting, and are keen to learn from results and increase the business value as fast as possible.

These ever-changing business requirements have to be pushed fast in the system to measure the impact. Traditional software development cycle could be long and tedious. The core of the problem starts from here. Longer the cycle, more is the number of issues. Each developer gets a copy of the code from the repository. All developers begin at the same starting point and work on adding a new feature. After that, all developers keep on changing and adding the code. Everybody is working on their own task. As the team finishes its work, everyone starts pushing their code to the central repository. Here, the problem starts. Code in the central repository is changed or some method signature is changed. Alternatively, there may be some API changes, tests start failing due to unknown changes done by another teammate in same feature code, there may be issues in merging the code, there may be compile conflict and test conflict, and so on. After that, there starts another cycle to fix these issues, which extends the release cycle a bit more. Things do not end here, before rolling out these new changes. Also, tests regarding the overall performance of the system are required to gain confidence that the software is working efficiently. So, there is much manual QA testing, slow release changes, manual performance test, and so on. Lots of manual work! Phew!

Where has the word "rapid" gone? Think of another situation. A developer made changes locally, and local tests do the unit test. The developer commits the code, and the continuous Integration (CI) system checks the code and runs the entire suit of test cases on it to confirm that the latest committed code doesn't break the build and make sure there is no compile time issue. This might cause tests to run 1000 times a day. Successful builds are auto deployed to staging where application acceptance test cases are run. After successful pass of test cases, the staging environment built will be ready as a good candidate of production release.

The basic idea of CI is to integrate continuously. A simpler definition of CI, which I have come across, is CI is the practice of testing each change done to your codebase automatically and as early as possible. The simpler the idea looks, the harder it appears to implement in practice.

To implement CI concepts, you need some fantastic tools for testing for UI as well as backend. Here is a list of tools that you can use to start testing UI:

• Jasmine (JavaScript)
• Selenium (UI testing)
• CasperJs (UI testing)
• Cucumber or Lettuce

The advantage of running all tests immediately for every change is that you know right away if something broken. Any failure can be fixed right away. Automated tests are useful if it runs with every change and continuously. CI is the first step towards continuous deployment.