Is Continuous Integration nowadays intended as “Continuous Inspection”?

Question

I've been reading a log about CI (mostly Addison-Wesley books) and taking "CI" courses. I see two clear distinctions between old books on CI and new ones:

• Old ones focus on "committing" or "pushing" your code often (integrating often)
• New ones talk about practices for having feedback early in the process, like running builds and tests in a pull request instance.

I think it's not common nowadays to commit or push every day (or multiple times per day), but it's a great practice to build and run tests in every pull request. Is it still Continuous Integration? Or am I missing something?

Edit: I'm following Martin Fowler's definition: "A software development practice where members of a team integrate their work frequently, usually each person integrates at least daily—leading to multiple integrations per day"

In the context of Git, I understand it as pushing/committing your code to the "development" branch daily. Maybe I'm mistaken, and it refers to a "working" or "feature" branch.

Answer 1

This question appears to be based on two false premises.

First, it is common to commit code every day. When I write code, especially at work, I commit my code to a local branch frequently, after sets of logical changes. It's not uncommon for me to make several pushes to a remote branch several times a day and also to ensure that branch is synchronized with upstream branches. In extreme cases, across an organization, you have multiple commits to your mainline every day. If you are performing Continuous Deployment, every commit to the mainline represents not only integration, but also deployment. In 2015-2016, Amazon was deploying new code to production every 10-15 seconds, on average. Doing this with any hope of stability also required integration.

Second, builds and tests are not only run in the context of a pull request. Not all teams or organizations use pull requests. Builds and tests can often be executed against any remote branch. In many cases, the system under development can be built and pass in a local development environment before reaching a remote branch and a pull request.

Integration is about combining one thing with a whole. This can happen in a feature branch that is synchronized with an upstream development or mainline branch for the purpose of a code review or it can happen in development or mainline branches for the purpose of delivery or deployment to an appropriate environment. Either way, integration often involves pulling upstream branches into the development branch, committing all of the changes, and pushing to a remote branch that is read from for the purposes of creating a build and executing tests.

Continuous Integration is about doing integration frequently. Initially, Continuous Integration was meant once a day. As the tools and technology changed and improved, it was found that you can perform integration multiple times per day.

Answer 2

The first mention of continous integration is in 1991 book by Grady Booch 'Object Oriented Design: With Applications'. In there is this chapter on Testing (this is in second and third editions, I'm unable to confirm if this is in first edition):

Testing

The principle of continuous integration applies as well to testing, which should also be a continuous activity during the development process. In the context of object-oriented architectures, testing must encompass at least three dimensions.

1. Unit testing involves testing individual classes and mechanisms. It is the responsibility of the application engineer who implemented the structure.
2. Component testing, which involves integration testing a complete component, is the responsibility of the component lead. Component tests can be used as regression tests for each newly released version of the component. Note that the term component is generic and can mean a single component in a small project or a collection of components, sometimes referred to as a subsystem, in a larger project.
3. System testing involves integration testing the system as a whole and is the responsibility of the quality assurance team. System tests are also typically used as regression tests by the integration team when assembling new releases.

So continous automated testing was part of continuous integration since the very beggining.

Same can be said about continuous integration as part of eXtreme Programming. Where continous integration is paired with TDD to ensure that commits made into master don't break existing functionality and make other's work more difficult before it is fixed.

Answer 3

System integration is defined as:

the process of bringing together the component sub-systems into one system (an aggregation of subsystems cooperating so that the system is able to deliver the overarching functionality) and ensuring that the subsystems function together as a system, and [...] as the process of linking together different computing systems and software applications physically or functionally, to act as a coordinated whole.

If we are talking about a software library, "integration" could mean running the library's test suite in Travis.

If we are talking about an operating system, "integration" could mean installing a copy of the operating system which requires, at a minimum, to build all of the component software.

Depending on what is popular at the time a book is written (such as compiled vs interpreted languages, small vs large projects, etc.), examples of "continuous integration" given may change. The principle, I would argue, remains the same.

Answer 4

There are basically two aspects to CI:

• Be able to deliver a current application at any moment
• Get early feedback on bugs

These are related of course (you need the first in order to produce the latter) and I can imagine the focus has shifted from the first to the second.

Because this mindset stimulates working in short cycles, you are not encouraged to look beyond the next feature and this can easily result in a terrible product that is hard to maintain. No one cares about the greater picture, everything is focused on the next feature. This increases the need for more, and more frequent testing because you will end up with the kind of product that breaks in an unexpected place after you apply a change.

So the more you embrace the first, the greater your need for the second will become. This may not have been obvious to the writers of the first wave of books.