Difference between revisions of "Continuous Delivery: Definition and Principles"

From Gcube Wiki
Jump to: navigation, search
(Definition)
Line 23: Line 23:
 
* Avoid having continuous delivery before making code reviews enforced by the build system.
 
* Avoid having continuous delivery before making code reviews enforced by the build system.
 
* Block artifact deployments except for the build user
 
* Block artifact deployments except for the build user
 +
 +
''Back to the [[Continuous_Integration_procedure_(2019) | CI guide]].''
 +
 
* Make it possible to start everything completely from scratch
 
* Make it possible to start everything completely from scratch
 
* Do not have any snapshot dependency during releases
 
* Do not have any snapshot dependency during releases
 
* Do not use version ranges in dependencies, because it prevents reproducible builds
 
* 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.
 
* Keep most logic inside Maven and Git to keep it reusable everywhere, without need of a build server.

Revision as of 19:19, 20 June 2019

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 how we see it.
  • No human intervention should be required. All decisions can be calculated automatically
  • 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.
  • Branch builds must enforce building from the top, never to be parameterized for building custom changesets.
  • Avoid having release branches.
  • Avoid having continuous delivery before making code reviews enforced by the build system.
  • Block artifact deployments except for the build user

Back to the CI guide.

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