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

From Gcube Wiki
Jump to: navigation, search
(Created page with "= 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....")
 
(Principles)
Line 24: Line 24:
 
* 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:16, 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.

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