View source for Continuous Delivery: Definition and Principles

= Definition =

''Continuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time.
You’re doing continuous delivery when:
*	Your software is deployable throughout its lifecycle
*	Your team prioritizes keeping the software deployable over working on new features
*	Anybody can get fast, automated feedback on the production readiness of their systems any time somebody makes a change to them
*	You can perform push-button deployments of any version of the software to any environment on demand
''Martin Fowler  

Continuous Delivery is producing software faster rather than in big release cycles over weeks or months, so that there exists at any time a stream of potential production grade versions of gCube artifacts that are ready to be released.
The difference between integration builds and delivery builds is that delivery builds publish artifacts as software versions. Typically, projects have many integration builds for verifications, validation etc. but artifacts are published only regularly or manually during a formal release cycle.

gCube achieves Continuous Delivery by continuously integrating the software crafted by the development team, building executables, running automated tests on those executables to detect problems and automatically packaging and distributing complete releases on the Maven Repository. Continuous Deployment is the only part gCube does not support yet.

= Principles =
gCube applies the following principles to Continuous Delivery:
* A regular build is no different than a release build. What makes a release special is where we upload the artifacts.
* No human intervention should be required. All decisions can be calculated automatically
* Avoid having release branches.
* If you have multiple branches for some reason, have a dedicated build job for each one of them, in order to see and manage the current branch status easily.
* Avoid having continuous delivery before making code reviews enforced by the build system.
* Block artifact deployments when the build is not compatible with the settings (e.g. a snapshot build with a master on release version).
* Make it possible to start everything completely from scratch
* Do not have any snapshot dependency during releases
* Do not use version ranges in dependencies, because it prevents reproducible builds
* Keep most logic inside Maven and Git to keep it reusable everywhere, without need of a build server.

''Back to the [[Continuous_Integration_procedure_(2019) | CI guide]].''

[[Category:Continuous_Integration]]