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