|
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.
|
|
