Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • We'll not use hotfix branches
  • We'll use the term develop development branch (not instead of integration branch)
Continuous integration

VCS (

Hudson

git)

The following branches will

Development branch

  • Will have a
continuous integration
  • proper hudson job
running
  • master
  • release branches
  • develop

Build (maven)

  • same snapshot version (develop and master)?
    • see open Issues

Maintenance

  • no changes
  • no hot fix branches (for the moment)

Feature branches

  • Rule: revert immediately as soon as it fails

Master

  • Scrum masters merge at the end of the sprint (develop -> master)

Feature branches

  • not on central repo (? - see open issues)
  • remove them after the final merge
  • list of feature branches --> things we are actively working on or are waiting
  • how to remove the branches?

Rules

Build (maven)

  • same snapshot version (develop and master)?
    • see open Issues

Maintenance

  • no changes
  • no hot fix branches (for the moment)
  • central repo
    • no feature branches
  • merging at the end of the sprint (develop -> master)
    • scrum masters
  • on develop branch
    revert immediately as soon it fails

Open Issues

Sharing feature branches [Daniel]

  • How to share them without having them on the central repo
    • ppl could define remote repos on others computers
      • potentional spider net: over time every dev could work with every other...
      • no out-of-the-box backup
      • hard to track what's being worked on (if not merging frequently from and to dev)
  • According to Greg nothing speaks against having them in central repo!

Version conflicts for snapshots [Daniel/Gregory]

  • do we need a special version?
  • other repository?
  • dev classifier?
  • something has to guarantee that not the wrong versions are used on the master!

Continuous integration

  • to have a chance to reveal conflicts pretty soon we have to 
    • frequently (daily?) merge from development to feature-branch (to get in stuff from other devs)
    • frequently (daily?) merge back from feature-branch to development branch
    • Difference to directly working on development branch
      • less blocking of others
      • easier to wipe not-working stuff without leaving traces
      • can easily squash commits related to one feature
      • frequent merging (dev-feature, feature -> dev)

Branching effort

Creating branches and merging is cheap in git - but if you have to touch lot's of modules it might no longer be the case

  • As we almost have a one git-repo per module setup feature branching might involve quite an effort in maintaining branches
    • e.g. for metadata-as-mixin we have to create (later merge then delete) branches for magnolia_main, magnolia_ui, ce-bundle, stk?, etk?, demo-project?,...

Links

By the way: feature branching vs. continuous integration has heavily been debated - mainly because of Martin Fowler's vote to not go for feature branches. Here's a bunch of links around it: