+91-7710033016 / +91-8291749529 support@effectivepmc.com

In Continuous integrations, all the developer work is merged to main branch several times a day. This helps in reducing integration problems.

In Continuous integration we try to minimize the duration for which a branch remains checked out. A developer code gets early feedback on the new code added to main repository by using Continuous Integration.

Implementing Continuous Integration

The practice of Continuous Integrations (CI) relies on certain pre-requisites being in place.

Version Control

Everything in your project must be checked in to a single version control repository which may include

  • Code
  • Tests
  • Database Scripts
  • Builds
  • Deployment scripts
  • Anything required to create, install, run and test your application

An Automated Build

You must be able to start your build from the command line. You can start off with a command-line program that tells you IDE to build your software and then runs your tests, or it can be complex collection of multistage build scripts that call one another. Whatever, the mechanism, it must be possible for either a person or a computer to run your build, test and deployment process in an automated fashion via the command line.

IDEs and CI tools have become pretty sophisticated these days, and you can usually build your software and run tests without going anywhere near to command line. However, you should still have build scripts which can be run from command line without your IDEs. This is since you would need to run your build process in an automated way from your CI environment.

Agreement of the Team

CI is a practice, not a tool. It requires a degree of commitment and decipline from your development team. You need everyone to check in small incremental changes frequently to main line and agree that the highest priority task of the project is to fix any changes that break the application. If people don’t adopt the discipline necessary for it to work, your attempts at continuous integration will not lead to the improvement in quality that you hoped for.

Best Practices of Continuous Integration

Some of the Best Practices of Continuous Integrations are

  • Build Automation : In CI, we create such a build environment that even with one command build can be triggered. This automation is done all the way upto the deployment to Production environment.
  • Main Code Repository: In CI, we maintain a main branch in code repository that stores all the Production ready code. This is the branch that we can deploy to Production any time.
  • Self-testing Build : Every build in CI should be self-tested. It means with every build, there is a set of tests that runs to ensure that changes are of high quality.
  • Everyday commit to baseline : Developers will commit all of their changes to baseline everyday. This ensures that there is no big pileup of code waiting for integration with the main repository for a long time.
  • Build every commit to baseline : With automated continuous integration , every time a commit is made into baseline, a build is triggered. This helps in confirming that every change integrates correctly.
  • Fast Build Process : One of the requirements of CI is to keep the build process fast so that we can quickly identify any problem.
  • Don’t Check In on a Broken Build : The cardinal sin of CI is checking in on a broken build. If the build breaks, the developer who broke it has to build it and get it working at the earliest.
  • Always run all commit tests locally before committing: Running a commit tests locally is a sanity check before committing to the action. It is also a way to ensure that what we believe to work actually does.
  • Production like environment testing : In CI, we maintain a production like environment also known as pre-production on staging environment, which is very close to the Production environment. .We perform testing in this environment to check for any integration issues.
  • Publish Build Results : We publish build results on a common site so that everyone can see these and take corrective actions.
  • Deployment Automation : The deployment process is automated to the extent that in a build process we can add the steps of deploying the code to a test environment. On this test environment all the stakeholders can access and test the latest delivery.

Benefits of Continuous Integration

  • CI makes the current build constantly available for testing, demo and release purpose.
  • With CI, developers write modular code that works well with frequent code check-ins
  • In case of a unit test failure or bug, the developer can easily revert back to the bug-free state of the code.
  • There is drastic reduction in the chaos on release day with CI practices
  • With CI, we can detect Integration issues much earlier in the process
  • Automated testing is one very useful side effect of implementing CI
  • All the stakeholders including the business partners can see the small changes deployed into pre-production environment. This provides early feedback on the changes to software.
  • Automated CI and testing generates metrics which helps in improving the development options.

Continuous Integration and Distributed Teams

Using continuous integrations with distributed teams is, in terms of process and technology, largely the same as in any other environment. However, the fact that the team is not sitting together in the same room – perhaps are not even working in different time zones does have an impact in some other areas.

  • For Distributed teams within the same time zone, the continuous integration is much the same.
  • For distributed teams in different time zones, there are more issues to deal with. If the team in USA breaks the build and goes home, this can be a serious handicap for the team in India. The process does not change bt the importance of adhering to it is magnified.
  • Some of the more powerful continuous integration servers have facilities such as centrally managed build farms and sophisticated authorization schemes that allow you to provide continuous integration as a centralized service to large and distributed teams.
  • It is also worth considering to move to a distributed version control system such as Git that allows people to check in even when there is no link to the conventionally designated “master” server. In Git, contributions are made first by forming the repository of the project you wish to contribute to, making your changes and then asking the owners of the original repository to pull your changes if they are working all-right.
  • Having a local version control system can also be an option in worst of circumstances. However it should be avoided as much as possible.

For more information on installation of Jenkins click here