1. What is the relationship between the code in the main branch and the code in the develop branch?
2. What assurance does the testing on the develop branch provide that the feature branch is suitable to merge into the main branch?
I mean, presumably you've got main and develop because they need to be different. But then, because they're different, you're never really testing the code that you actually deploy. Superficially, it seems both more complicated and less reliable than trunk-based development.
What am I missing? Why would this way of working be helpful?
> But then, because they're different, you're never really testing the code that you actually deploy.
That's true, and I alluded to it in my comment. It's conceivable that feature-1 and feature-2 are simultaneously in develop, feature-1 gets tested successfully and is merged into main; and then it turns out you needed feature-2 to actually fulfill all requirements. Seems like it'd happen all the time, but in practice, it just doesn't. Probably a combination of unit tests, backend code being written in a static language, and developers, qa, and pms using their head.
> Why would this way of working be helpful?
Having little experience with anything else, it's difficult for me to say. It seems quite flexible: we release individual features or, sometimes, related features that are compounded into a feature branch.
Main essentially never breaks, and it's nice that you can essentially deploy it whenever you want without explicitly packaging a version and testing it. That seems to be the idea behind trunk-based development, too.
But then, develop does break occasionally (i.e. a bug was discovered during testing), and it's nice that this is allowed, as well. Having to revert a feature branch from trunk because a bug was discovered sounds terrible, and also what if you released trunk in the meantime? It sounds to me like it could only work if the feature branches itself are the subject of QA (and then you have a similar problem as testing our develop branch).
> The develop branch is main + feature branches currently in qa.
Is any work done to ensure this, or is it just a byproduct of the way of working?
One more question. What if instead of this dev branch people just asked the QA system to run on their feature branches? Would that generate too much work?
I'm imagining that the flow you describe is some kind of convenient or less expensive version of that.
I agree though that testing the feature branch on the develop branch is not the same thing as that feature branch living in main, because some other feature branch in develop branch may be indirectly affecting the original feature branch.
I barely use git in any meaningful way so these questions are coming purely from outsider curiosity.
(As an embedded developer, it would be bliss to experience 'develop gets deployed semi-hourly'...)
You've identified what I'd call the main weakness, but in practice it hasn't been an issue. I've discussed it in a bit more detail in a sibling post. Ymmv.
I would call it trunk based development, since feature branches are short lived.. Most MR are just 1 or 2 commits. Just part of our review process.
When a developer is happy with their feature branch, they open a pull request to develop, which gets reviewed by another developer and, eventually, merged to develop.
The code in develop gets deployed semi-hourly or on demand to a testing environment, where quality assurance takes on the feature branch.
Eventually, when the testers are happy with the feature branch, it gets merged to the main branch. Main gets deployed to production daily, or on demand. There are no release branches or tags.
Feature branches that take longer are periodically rebased on main (or main gets merged into the feature branch). On rare occasions, hotfix branches are merged directly to main (and immediately, possibly partially, deployed). That code lands in develop via an automatic merge process from main to develop.
The weakness of the model would appear to be that testing practically never happens on the main code branch. I say practically, because we do have a staging environment that reflects the main branch code version, but it's almost unused. It just hasn't been an issue in a decade+ working this way with a team of 8-20 developers. Maybe it doesn't scale to much larger teams?
Someone help me out, is there a name for this model? It doesn't appear to be gitflow, which IIUC periodically transforms (or merges) the entire develop branch into main branch (we never do this). But it also doesn't sound like it's trunk based development, which doesn't seem to have a develop branch, and also uses versioned releases. We can't be the only ones doing it this way?