3 ms·

We have a main branch, and a develop branch. Feature branches are based on the main branch. When a developer is happy with their feature branch, they open a pu

by morsch 4y ago

We have a main branch, and a develop branch. Feature branches are based on the main branch. 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?

loupol 4y ago
I've definitely seen the same model used. Small company also.
civilized 4y ago
What I don't understand about this model is 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?
- morsch 4y ago
  The develop branch is main + feature branches currently in qa. > 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).
  - civilized 4y ago
    Thanks, this mostly makes sense now. > 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? I'm struggling to understand how it would just happen automatically.
    - morsch 4y ago
      Well, it's manual in that when a developer thinks they're done, they open a pull request from feature branch to develop. That's where code review takes place, and as such it's a core part of the workflow. Failing qa might mean additional commits on the feature branch and another pull request to develop. (Develop should really be called testing or qa; historical reasons.)
kkapelon 4y ago
Gitflow and TBD are just two of the many possible ways to use Git. Several companies (such as yours) use other systems that have no name. And that is fine. We don't need to name every possible variation of a Git model.
- morsch 4y ago
  If it doesn't have a name, I might give it one and document it more formally than in a hacker news comment. I was under the impression that most teams implement one of a handful of standard models. But it's possible that you're right that there's more variation to it than I thought.
dezgeg 4y ago
Maybe I misunderstood your description, but does 'develop' not ever merge to 'main' directly? Your description sounded like QA could for example test 'develop' which is main + featureA + featureB, give that a green light, and then have new main be main + featureA (which has been never tested). That does sound bit dangerous. (As an embedded developer, it would be bliss to experience 'develop gets deployed semi-hourly'...)
- morsch 4y ago
  No, develop never gets merged to main. In fact, I've been meaning to add a dummy commit to develop and a commit hook that declines it being merged to main, to ensure nobody merges it by accident. One of these days... 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.
TeeWEE 4y ago
We use a similar model, but only one "main" branch, which get a tag when released. 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.
- morsch 4y ago
  How often do you release? Is there any manual qa (as opposed to unit or integrating tests)? Does a bug in one feature block the release of others (because it means main has a bug)?
deleted 4y ago
[deleted]

by morsch 4y ago

loupol 4y ago

I've definitely seen the same model used. Small company also.

civilized 4y ago

What I don't understand about this model is 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?

morsch 4y ago
The develop branch is main + feature branches currently in qa. > 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).
- civilized 4y ago
  Thanks, this mostly makes sense now. > 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? I'm struggling to understand how it would just happen automatically.
  - morsch 4y ago
    Well, it's manual in that when a developer thinks they're done, they open a pull request from feature branch to develop. That's where code review takes place, and as such it's a core part of the workflow. Failing qa might mean additional commits on the feature branch and another pull request to develop. (Develop should really be called testing or qa; historical reasons.)

kkapelon 4y ago

Gitflow and TBD are just two of the many possible ways to use Git. Several companies (such as yours) use other systems that have no name. And that is fine. We don't need to name every possible variation of a Git model.

morsch 4y ago
If it doesn't have a name, I might give it one and document it more formally than in a hacker news comment. I was under the impression that most teams implement one of a handful of standard models. But it's possible that you're right that there's more variation to it than I thought.

dezgeg 4y ago

Maybe I misunderstood your description, but does 'develop' not ever merge to 'main' directly? Your description sounded like QA could for example test 'develop' which is main + featureA + featureB, give that a green light, and then have new main be main + featureA (which has been never tested). That does sound bit dangerous. (As an embedded developer, it would be bliss to experience 'develop gets deployed semi-hourly'...)

morsch 4y ago
No, develop never gets merged to main. In fact, I've been meaning to add a dummy commit to develop and a commit hook that declines it being merged to main, to ensure nobody merges it by accident. One of these days... 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.

TeeWEE 4y ago

We use a similar model, but only one "main" branch, which get a tag when released. 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.

morsch 4y ago
How often do you release? Is there any manual qa (as opposed to unit or integrating tests)? Does a bug in one feature block the release of others (because it means main has a bug)?

deleted 4y ago

[deleted]