Looking for git workflow idea for short, infrequent sprints

[vhe1]

Hi!

We just got a legacy project (asp.net mvc app of, say - questionable - quality), are four developers plus one product owner (we do scrum) and we are supposed to work on it for one or two days every month, possibly even less, i.e. a couple of days every few months.

The current flow is that we branch features off develop and have no other branches. The workflow is that

1. We develop each feature on a branch and test.
2. After or near the end of the sprint, another tester tests each feature branch.
3. After that, the stuff that works gets merged to develop.
4. Develop gets tested again.
5. Things get deployed.

The problem I have is that, due to the short duration of the sprint, we can’t really merge stuff back to develop for other feature branches to be updated with finished features. So, bugs introduced by merging are discovered late, if at all.

Also, we have three kinds of tasks:

1. Small, isolated tasks (change the text on a view).
2. Tasks that may break stuff (adding a field to a database).
3. Refactorings which, by their nature, affect lots of files.

Now, is the flow we have ok for these tasks? Should we use different ways of working with the different task categories?

Would the full git flow be an advantage? Or does anyone have an even better idea?

Any help would be greatly appreciated.

[lee-dohm]

This isn’t really a Git question, but more of a general software development philosophy question 😀

It sounds to me like the lion’s share of the testing occurs in step 2 of your flow and step 4 is more of a “sanity check”. If you’re not catching enough bugs pre-merge, then your process should focus its testing effort on testing post-merge.

Your three classes of changes are pretty much standard. Every software project has some of each of those changes.

I’m not sure what you mean by “the full git-flow”. It sounds like you’re doing that already. Here’s the process that we recommend for use on GitHub. We recommend this process for changes of all sizes. If some changes are particularly large or long-running, then we tend to merge from the default branch (develop in your case) into the PR branch at regular intervals along the way. We do this to ensure that we’re testing the right thing all the time.

Do you have automated tests helping with the testing workload?

[vhe1]

I think that has cleared it up for me beautifully, including that link to the flow you use.

Thanks a lot!

(Yes, we do have automated tests, which could use some improvement, but that need is clear and the flow is not intended to replace automated tests.)