What Continuous Integration (CI) is not?

Just setting up builds in Jenkins is not Continuous Integration

Setting up builds in Jenkins or any other Continuous Integration tool like CruiseControl, TFS or Bamboo is basically just setting up automated builds. CI implies continuously integrating pieces that are right themselves and also play well together. In order to make sure that we are integrating right, we need tests at every step: compile — run unit tests — deploy to a test environment — run integration tests. These tests need to be set up as jobs in the CI tool and get triggered automatically when the previous steps pass. These tests catch issues as soon as they happen or when they pass, they give us the confidence that we are indeed building the right thing. So… there can be no CI without tests.

Continuous Integration is impossible with code in several branches

I have seen teams set up automated builds on several feature branches and then deploy the branch artifacts to different machines. Then they run tests on the products from these branches. Since each branch does not include the code or the associated functionality from the other branches, many tests fail. The test failures, however are not investigated because it is known that some of the product functionality or fixes reside in other branches. Towards the end of the sprint, these branches are merged and the merged changes get deployed to a test environment. This is the first time the changes are integrated. Notice the problem? Too much code is integrated too late in the development process when finding and fixing issues is very expensive. So… there can be no CI with code in branches; CI only works when everyone checks in to 1 mainline branch.

Continuous Integration with manual steps is bound to fail

Manual deployment procedures or needlessly complicated build processes or processes that are environment specific are all problems by themselves. Incorporating these into CI is just asking for more trouble. The goal should be to automate everything in the CI pipeline so these CI steps happen automatically and can also be triggered by anyone in team by easily clicking a button. By eliminating the manual steps, the build-test-deploy cycle runs in the background every time any small change is checked in without any human intervention. This is very essential to ensure that changes get integrated continuously, without fail every single time. So… CI with manual steps is bound to have setbacks.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.