What is Continuous Integration?

[joerg.hampel]

(this post was triggered by another discussion)

I don't want to be extra picky about which words we choose here in our discussions. What I'm seeing, though, especially in our ecosystem, is people using the term CI or CI/CD or Continuous Integration for anything that has to do with triggering some process by/through source code control. This is not a problem, but I still feel like it's not technically correct. I've long wanted to hear other people's opinion on this. 

The way that I understand Continuous Integration, it describes a workflow or process model rather than a technology. So the fact that somebody is executing LabVIEW through Jenkins or GitLab CI or similar services does not mean they are doing CI. "Continuous Integration" literally means adding your changes to your application all the time. There's not even a need for any automation or build servers etc., you can perfectly well integrate continuously on your own local machine.

For continuous integration as I understand it, the size of the team isn't a relevant factor, either. The integration is not done with other people but with the main line (branch) of the application. 

We (my company) don't do continuous integration. We use the gitflow model and work in feature branches, which we integrate with the main development branch only after the feature has been completed and tested. We trigger our server-side automation once a feature is completed and the feature branch is merged back into develop, or once a release is finished and merged into main/master. This workflow model has pros and cons, and we're always looking at alternatives. So far, we feel like it serves our own use case best.

I'm curious to hear other people's take on this.

[Taggart]

Yes in the LabVIEW Community, people often use CI to refer to automation. I've even done it. If you study the literature though, it is often referred to trunk based development. The goal is that every change immediately gets integrated with everyone else's changes. Automation is used to run tests to make sure you don't break things and it still builds, but that is not the point. The point is to integrate often so that the integrations themselves are easier and less prone to introduce bugs. It is the antithesis of feature branching, where you work an a feature in its own little sandbox and don't integrate with everyone else's code until you are done. Even then you are not integrating with everyone else's code, because they are also presumably working in their own branches.

So in short if you have feature branches, especially long-lived ones you aren't doing CI in the classical sense even if you automatically run tests and builds. Nothing wrong with that if it works for you, just not classical CI.