How is Continuous Integration different from using git to integrate external code?

Question

I have a conceptual doubt about CI using Jenkins. I know Jenkins can help me to integrate all code built by developers.

So the question is: How is this not already resolved with Github (or any other git tool)?

I can run git stash, git pull origin master, and/or git stash apply to integrate other code with my code.

So I think I am misunderstanding something about continuous integration. Can you clear my mind?

Answer 1

Merging code changes is definitely handled by Git and its tools. But Continuous Integration also includes testing and building the software. The development teams are provided with constant feedback on the status of their branch(es) and whether they are failing tests, builds, etc.

Jenkins provides the tools to enable this feedback. By creating a CI "pipeline" in Jenkins the developer gain much better insight into the build, beyond what simple Git merges and stashes provide.

Answer 2

Continuous Integration with Jenkins would handle code integration but that would not be its only role. This is what I think you are missing.

For continuous integration, you would also run your testing stack and product building steps. However, if you don't have testing (I would highly recommend it) and you have no need for a building stage, git would do just fine.

Answer 3

To extend others' answers, CI allows to have a "single place of truth" how the software builds and runs in terms of system environment dependencies.

With the rise of infrastructure as code you could of course say okay I have git to put my Dockerfiles for example but this makes somehow no sense.

Many open source projects on GitHub verify validity of pull requests through CI untegration and do double, even triple checks, that is even just one CI system appears not enough to achive high quality.

Answer 4

There are 2 aspects of the software integration (be it continuous or not):

• performing the technical steps to integrate multiple changes - which is what you're referring to in the git-based environments
• checking the quality of the integrated code - in the traditional CI methodology this is what Jenkins and other CI tools do

Jenkins won't technically do the integration steps itself, AFAIK it is not capable of doing that. Its operation is only triggered after the technical integration steps are completed, typically by the developers (in your case after you git commit and git push your changes to origin).

There is a different kind of CI tools out there, the gating-commits ones, which actually perform the technical integration, run the QA verifications on the result and, only on success of the verification, they also merge the result into origin. They effectively do the entire software integration work and are thus capable of guaranteeing no QA regressions in the end result.