Code will be delivered under Continuous Integration (CI) although traditionally code would be merged several times a day this may be less frequently

When embarking on a change, a developer takes a copy of the current code base on which to work. As other developers submit changed code to the source code repository, this copy gradually ceases to reflect the repository code. Not only can the existing code base change, but new code can be added as well as new libraries, and other resources that create dependencies, and potential conflicts.

The longer a branch of code remains checked out, the greater the risk of multiple integration conflicts and failures when the developer branch is reintegrated into the main line. When developers submit code to the repository they must first update their code to reflect the changes in the repository since they took their copy. The more changes the repository contains, the more work developers must do before submitting their own changes.

Eventually, the repository may become so different from the developers' baselines that they enter what is sometimes referred to as "merge hell", or "integration hell", where the time it takes to integrate exceeds the time it took to make their original changes.

Continuous integration involves integrating early and often, so as to avoid the pitfalls of "integration hell". The practice aims to reduce rework and thus reduce cost and time

A complementary practice to CI is that before submitting work, each programmer must do a complete build and run (and pass) all unit tests. Integration tests are usually run automatically on a CI server when it detects a new commit.

Continuous Integration or CI is a practice used by the developers which requires every single developer in the team to integrate his/her code into a shared repository several times a day. Each individual check-in is always verified by an automated build process, thus allowing the team to detect the problems at an early stage. This automated build script can also include executing the test suite for the entire application, thus ensuring that the code which is in the repository is a stable version

Read more: http://mrbool.com/how-can-continuous-integration-be-performed-using-jenkins/32717#ixzz4esvtbtx2

A part of the facilitation of this, Automated build will be implemented through the Use of Jenkins

Continuous Integration Best Practices: Vision and Reality HERE