English French
CI Manifesto
Continuous integration is a developer/packager process and workflow. Continuous delivery is a release process and workflow.
Continuous integration aims to ensure broken changes do not affect other developers, packagers, maintainers or users. Continuous delivery aims to ensure broken changes do not get delivered or released.
Continuous integration allows us to rapidly course correct while building software toward a moving target.
The feedback that continuous integration provides is vital for fast paced agile delivery of software.
Late testing, long after a change occurs, does not scale to the pace of Fedora.
Because there are several Continuous Integration efforts, we need to set the basic rules to make sure we’re all playing the same game. When we call a game “football” we need to agree on what that means. We may have different frameworks, implementations or tests, but need to play the same game.
The Definition
*You don’t get to call it “Continuous Integration” unless you ...*
Assemble it together like in production, then test drive it like a user. This is *Integration*.
Do those integration tests for every single "change". This is *Continuous*.
Without these, it may be “unit testing”, “acceptance testing”, “regression testing”, “quality assurance”, or other steps in the pipeline … but it’s not “continuous integration”. You might even run the same tests again later as part of one of these other testing processes.
Building a component, composing it with others, assembling it into a production-like system, is all part of integration. A “change stream” is how we refer to the changes that integration continuously acts upon. A developer is someone who instigated and/or implemented the change and is our target for feedback from the tests. In Fedora this is a packager or maintainer. Usually we apply that integration to a stream of software changes, but at other times it is hardware changes, or other changes.
*Continuous delivery* is taking some of those successful integrations and delivering them.
The Manifesto
A test has zero value until its result affects the behavior of an observer.
The best observer for a test result is the developer or packager who instigated and/or initiated the change being integrated.
The benefit of continuous integration is inversely proportional to the size of the change. Many iterative small changes far outweigh a massive bundled change.
Rapid feedback to the developer or packager of the change will cause them to pay attention. Aim for hours not days to provide test results.
Packagers only take responsibility for tests that they can contribute to.
Packagers respect tests and testing systems that produce reliable results. Conversely they ignore and shun tests and systems that are flakey.
Packagers should not have to search for test results outside of their workflow.