I'm evaluating GitLab Flow as a potential branching strategy for a team of about 20 developers. The process that's unclear to me is how changes are "promoted" to the higher environments.
Following the example in the linked document, let's assume I've got three environments with branches to match: Staging, Pre-Prod, and Production. My understanding is that, once testing passes on Staging, the entirety of the Staging branch is merged into Pre-Prod for additional (broader) testing. Now, suppose that Feature A and Feature B are both in development by two separate developers and being tested in Staging. Feature A passes tests, but Feature B fails for some reason and needs more work. It seems to me that that introduces a dependency between A and B, where A cannot be released to Pre-Prod without B because Staging cannot be merged to Pre-Prod until both pass testing. In my experience, it's likely that the developer of Feature A will move onto Feature C in the meantime, which may itself fail testing, creating a series of dependencies and preventing Staging from ever being in a state to merge to Pre-Prod. It's not unusual for our team to have 7 or 8 features in various states of readiness at any time, so this doesn't seem like an atypical occurrence to me.
Am I overlooking some aspect of this model, or is this feature interdependency baked-in? Has anyone using this strategy encountered this type of problem?
The only true solution that I see is to cherry-pick individual features from Staging into Pre-Prod. This sounds reasonable as a workaround to an occasional issue, but doing this for every feature seems like it would require an awful lot of overhead for someone managing the state of Pre-Prod.
It seems to me like this problem could be mitigated with more robust automated testing and feature flags, but even then there's never a guarantee that any particular developer's change has not introduced an unexpected regression.
