What does your Agile workflow look like, in particular release frequency and source-control management? [closed]

Question

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.

---

Want to improve this question? Update the question so it's on-topic for Stack Overflow.

Closed 3 years ago.

Improve this question

My team are discussing the most efficient way to manage releases to our users. This is our current workflow for our 2 weeks sprint cycles:

1. We develop everything on trunk
2. We have a nightly Team City build that pushes to our Nightly Build server
3. Our BAs/QAs evaluate the nightly builds and decide when to promote to QA/UAT
4. At the end of the sprint, we push whatever's on trunk to UAT.

The biggest issue we're seeing with this is related to everything being developed on trunk. Because incomplete stories are checked-in to trunk, our nightly builds are occasionally buggy. This scenario can also occur at the end of the sprint, e.g. a Story consisting of 6 tasks (of which 3 are complete) has been checked in to trunk.

I'm of the opinion that a user should only evaluate the efforts of a complete Story or a fixed bug. A Story with 6 tasks isn't Done until those 6 tasks are complete.

One proposed workflow was this (but with some issues):

1. We develop on a 'sprint branch'. Everything done in the sprint is checked into this branch. When all tasks for a story are complete, the branch is merged to trunk and a nightly build is generated.
2. At the end of the sprint we merge to trunk.

The problems with this are that for step 1, when we merge to trunk we could also be merging incomplete Stories (and the same for step 2).

This leaves us with this proposed workflow:

1. For each Story, we create a Story/feature branch.
2. When a Story is complete, we merge from trunk (picking up other complete stories and bug fixes), and then merge to trunk. Trunk now contains a new completed Story.
3. We then generate a nightly build

This sounds like it could solve most of the problems associated with incomplete Stories. But, it introduces the complexity and overhead of multiple branches.

We'd be interested to hear what you do, and in particular if you:

• Develop on trunk
• Develop on a sprint-related branch
• Develop on feature/story branches

If you use one the branch approached, what overheads does that introduce, and is it worth it.

Answer 1

We develop on trunk, but we never have incomplete Stories at the end of the iteration. We don't have Stories that don't fit into one iteration. Bigger Stories are split into smaller ones.