What guidelines should be followed when using an unstable/testing/stable branching scheme?
Posted
by Elliot
on Stack Overflow
See other posts from Stack Overflow
or by Elliot
Published on 2010-03-10T19:38:29Z
Indexed on
2010/03/17
3:01 UTC
Read the original article
Hit count: 326
My team is currently using feature branches while doing development. For each user story in our sprint, we create a branch and work it in isolation. Hence, according to Martin Fowler, we practice Continuous Building, not Continuous Integration.
I am interested in promoting an unstable/testing/stable scheme, similar to that of Debian, so that code is promoted from unstable => testing => stable.
Our definition of done, I'd recommend, is when
- unit tests pass (TDD always),
- minimal documentation is complete,
- automated functional tests pass, and
- feature has been demo'd and accepted by PO.
Once accepted by the PO, the story will be merged into the testing branch. Our test developers spend most of their time in this branch banging on the software and continuously running our automated tests.
This scares me, however, because commits from another incomplete story may now make it into the testing branch. Perhaps I'm missing something because this seems like an undesired consequence.
So, if moving to a code promotion strategy to solve our problems with feature branches, what strategy/guidelines do you recommend? Thanks.
© Stack Overflow or respective owner