DevOps 360
What is Continuous Integration

What is Continuous Integration?

Continuous Integration (CI) is a development method in which developers merge source-code into a common repository on a regular basis, ideally many times per day.

Continuous integration is a DevOps software development approach in which developers integrate their code changes into a common repository on a frequent basis, following which automated builds and tests are done. Continuous integration is most commonly used to refer to the build or integration step of the software release process, which includes both an automated component (e.g., a CI or build service) and a culture component (e.g. learning to integrate frequently). The main aims of continuous integration are to detect and fix issues faster, increase software quality, and shorten the time it takes to verify and deploy new software upgrades.

Why is Continuous Integration Needed?

Because you’re integrating so regularly, there’s less backtracking to figure out where things went wrong, allowing you to spend more time implementing features.

Continuous Integration is not expensive. It is costly to not integrate continually. You’ll have lengthier times between integrations if you don’t use a systematic method. Finding and fixing problems becomes considerably more difficult as a result of this. Such integration issues can easily throw a project off track or cause it to fail entirely.

Your company will profit from continuous integration in a variety of ways:

  • Say goodbye to time-consuming and stressful integrations
  • Increased visibility allows for better communication
  • Catching problems early and putting them out of their misery
  • Spend less time troubleshooting and more time implementing new features
  • Create a strong foundation
  • Stop waiting to see if your code will work and start reducing integration issues  allowing you to deliver software faster

Continuous Integration is more than a process

Several key concepts and practises support Continuous Integration.

The practices

  • Keep a single repository of source code
  • Automate the build
  • Create a self-testing build
  • Every commit should be built on a CI machine
  • Maintain a quick build
  • Test in a production environment clone
  • Make it simple for everyone to obtain the most recent executable version
  • Everyone can see what is going on
  • Automate the deployment process

How to do it

  • Developers save code to their personal workspaces
  • When you’re finished, save the modifications to the repository
  • When changes occur, the CI server monitoring the repository and checks them out
  • The CI server builds the system and runs unit and integration tests
  • The CI server builds deployable artefacts available for testing
  • The CI server assigns a build label to the version of code that was just created
  • The team is notified of a successful build by the CI server
  • The CI server notifies the team if the build or tests fail
  • The problem is quickly resolved by the team
  • Throughout the project, continue to integrate and test on a regular basis

Team responsibilities

  • Frequently check in
  • Don’t check in any code that isn’t working
  • If the build is broken, don’t check in
  • After checking in, do not leave until the system has been build

Goutam Jha

Add comment

Your Header Sidebar area is currently empty. Hurry up and add some widgets.