|
|
| (10 intermediate revisions by one other user not shown) |
| Line 1: |
Line 1: |
| = Why =
| | #REDIRECT [[CI]] |
| | |
| == The Vision ==
| |
| | |
| There are hundreds of packages which make up the Operating System.
| |
| Making sure that they all work together as a whole is not an easy
| |
| task. This becomes even harder as the number of packages and their
| |
| inter-dependencies grows. An extensive testing is required before
| |
| a new version of the operating system is released to ensure it is
| |
| stable enough. That is the past.
| |
| | |
| Imagine an '''Always Ready Operating System''' which consists of
| |
| packages which are constantly kept in a good shape. Integrated
| |
| and stable thanks to an extensive test coverage which is
| |
| continuously executed upon changes in individual packages, in this
| |
| way allowing to prepare a new release in much shorter time, or
| |
| even in no time.
| |
| | |
| Imagine an operating system distribution which you could release
| |
| at any moment. This is where we are heading. Here comes the CI,
| |
| Continuous Integration, as an invaluable tool to ensure everything
| |
| is working together as expected in every point of time.
| |
| | |
| == CI Manifesto ==
| |
| | |
| Continuous integration aims to ensure broken changes are revealed
| |
| as soon as possible and do not affect other developers, packagers,
| |
| maintainers or users. 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. Learn about the steps that are crucial for a working
| |
| Continuous Integration in the [[CI/Manifesto|CI Manifesto]].
| |
