How to deliver software

From ym2149.org
Revision as of 11:20, 19 April 2024 by Andrzej (talk | contribs)
Jump to navigationJump to search

Guidance

Process

  • default branch should always be releasable
    • any developer starting a feature branch can be confident of a stable base
    • also merging a feature branch into the default branch does not build upon questionable code
  • a ticket is done when the changes are in production
  • split work feature by feature, not layer by layer
    • descope tasks that can later be fixed forward
  • squash merge makes the history less useful for investigations or revert
    • in particular, a story may result in a refactor commit followed by a feature commit. combining those throws away a ton of information and may make refactoring less attractive to developers. they should not be in separate pull requests as refactoring needs context or may be negative work, and benefits from a free round of testing
  • merge your own pull requests, own that responsibility
  • keep your own tickets up to date. in particular, only the assignee knows when it can really be moved to done e.g. experimental cloud resources may need to be tidied up