6 ms·

Isn't there a middle ground here? If you have CI/CD, you can eliminate release branches by just making PRs directly into main. The idea of post-merge code revi

by gsk22 5y ago

Isn't there a middle ground here? If you have CI/CD, you can eliminate release branches by just making PRs directly into main. The idea of post-merge code review is horrifying to me. I guess this is the "move fast and break things" attitude in action. Deploy now, catch bugs...sometime, maybe (TM)!

sdfaksdfjalj 5y ago
This is the way it's done at many major tech companies. Each individual commit is reviewed then merged directly into main/master. I've never used them but the thought of feature branches seems absurd versus simply merging small changes. Very rarely can a "feature" not be broken down into small self-contained changes.
Starlevel001 5y ago
> Deploy now, catch bugs...sometime, maybe (TM)! Given the state of literally all software I use, this seems to be the default behaviour.
Ozzie_osman 5y ago
I've found that to be a great middle ground on most teams. If you want to stretch it a little more, you could selectively do post-merge reviews for things that might be low risk (ie a UI change that's behind a feature flag that only your team sees), and keep riskier changes (like a big refactor, a data migration, etc) on the pre-merge review flow.
- deckiedan 5y ago
  We have pre merge review - but for trivial stuff, text / label changes, etc, put a "tiny" tag on the PR, and if urgent paste it to the slack channel asking for a glance and nod review... At least having another pair of eyes check text-only changes has caught so many typos, etc, and only takes a couple minutes.
PontiacParade 5y ago
I agree with the middle ground comment. That is how we tend to do things where I work. We have a modified GitFlow: main: is the source of truth and is what is in production. develop: is the constantly moving branch we make PRs against. You can commit directly here which is discouraged but it isn't a hard rule. ticket: is a branch for each JIRA ticket not each feature. release: We don't make these and just use tags on main. Each "release" is a merge from develop to main and that gets deployed. hot fix: These are made against main and merged back to develop when they are used. It is rare enough I have to look up our "official" procedure. With that we can easily use PRs, release code in small hidden chunks, do code reviews, etc. Seems like the big win they got was releasing small hidden chunks of a feature and deploying it to staging. They also gave up some nice things as well like code review before merging.
- chrisweekly 5y ago
  Yeah, feature flags are increasingly mainstream / worthwhile, but I hate the idea of giving up on not just CR before merging, but also "preview deploys" (from feature branches to ephemeral deploy envs).
- chx 5y ago
  For us, whether you commit directly to develop or create a branch is more of a decision whether QA needs to be involved . Once you are done, you merge with squash so develop has no merges and later it's not even visible whether you just committed into develop or worked in a branch. Obviously this might not work if your work involves large changes but we work in tiny bits.
- xyzzy_plugh 5y ago
  > ticket: is a branch for each JIRA ticket not each feature. This kind of thing really grosses me out. Why can't you just include the issue number in relevant commit messages? Why does it matter what your branches are named? Naming branches relevant to what they actually represent is incredibly important to me, personally. I don't care what you do but I refuse to play by this rule in particular, when it's a hard rule.
  - 5y ago
xupybd 5y ago
Context matters. What is the cost of a bug getting into the wild vs what is the cost of keeping the bug rate very low? If you're NASA or a high frequency trading company I'm guessing the cost of bugs can be very high. If you're making internal tools to automate admin tasks the cost of bugs is often very low.
- akyoan 5y ago
  > If you're NASA I don’t think it's fair to pick something extra-ordinary to respond to the article. Obviously "no worries" doesn't apply if the stakes are high.
  - xupybd 5y ago
    I'm not trying to say it's binary. That you're either NASA or your quality doesn't matter. NASA is only the furthest on one end of the scale that I could think of. There is a scale and you have to know where you are. There is always a trade off between the amount of work you can get done and the amount of QA process you have in place. With infinite resources it wouldn't matter but us programmers are expensive.
pcthrowaway 5y ago
I'm guessing this is a reference to "MIME, someday, maybe" - http://1997.webhistory.org/www.lists/www-talk.1993q1/0182.html http://1997.webhistory.org/www.lists/www-talk.1993q1/0182.ht...
shawnps 5y ago
To make this process safer I usually recommend: 1. Put all new code behind feature flags that are off by default in production. 2. Make rolling back easy. 3. Have extensive unit and integration tests. Some of the deployment steps could be automated even further -- maybe the CI server automatically deploys Staging after a successful build. See the books Accelerate: The Science of Lean Software and DevOps, and The Toyota Way for more.
- akyoan 5y ago
  > Put all new code behind feature flags How is that even possible? A comma change in a feature can break things, are you going to put that change behind a feature flag? "New code" isn't just "new files/functions", so it's not always feasible to keep it behind flags, unless you use a "copy on write" methodology to all code.
  - mkdirp 5y ago
    Parent commenter probably meant putting new features behind a flag. I work for a major feature management company and we heavily use our own platform. Yet we don't put "all code" behind feature flags but we do with features. It's nearly impossible to put "all code" behind feature flags.
    - shawnps 5y ago
      Right, basically this. If you're shipping something new that could affect production, put it behind a feature flag so the code paths that are already live are unaffected. Continuously ship small changesets so that it's easy to roll back if necessary.
      - dpark 5y ago
        > If you're shipping something new that could affect production… Which, again, is everything. I’m all for feature flags, but they cover very specific cases. There are many changes that feature flags cannot cover. The addition of the feature flags itself can introduce bugs. They are a great feature but only one small piece of protecting production.
DougBTX 5y ago
Yes, a good middle ground is the slightly confusingly named “GitHub flow”: https://docs.github.com/en/get-started/quickstart/github-flow https://docs.github.com/en/get-started/quickstart/github-flo... The main branch is always stable, releasable. Feature branches are branches off main, which are then merged back into main. No develop or release branches. It is like trunk based development, especially if branches are kept short and regularly rebased onto origin/main, but with a point to run PR checks before merging.
- pydry 5y ago
  This is how most people I know develop and have done for years but I've never heard anybody ever call it "github flow".
  - Traubenfuchs 5y ago
    I also lifted an eyebrow at this. It‘s just „trunk based development with feature branches and prs“.
    - pydry 5y ago
      It reminded me of when Microsoft used to pay people to say "just bing it".
      - the_fury 5y ago
        The term predates the Microsoft acquisition by a number of years.
        CRConrad 5y ago
        See cousin comment: https://news.ycombinator.com/item?id=29609937 https://news.ycombinator.com/item?id=29609937
  - dpark 5y ago
    I think it acquired this name to distinguish from “git flow”, an alternative way to use git that is, put politely, somewhat of a maintenance headache. https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow https://www.atlassian.com/git/tutorials/comparing-workflows/...
teknopaul 5y ago
What's makes you think that just because you code rewiew after it hits trunk that you deploy before review? I think the problem people have with trunk dev is they don't grok that some projects don't have the same deployment strategy as them. There is a thing called a code freeze. This is a common practice. Not everyone does it. Just because you do trunk dev does not mean you can't also have a feature branch to try stuff out or a release branch or any other number of branches. What trunk dev means is get your ode out there to other devs quick. Not necessarily get your code out to production or to QA or the customer quick. Those decisions can be independent of branch strategy.
- CRConrad 5y ago
  It's easy to confuse continuous integration and continuous deployment because they're so often mentioned in the same breath. Aren't they collectively called "CI/CD"? (Confession: At least I "think* this is an example of getting them confused. They are different things, right...? The same difference you mentioned?)

by gsk22 5y ago

sdfaksdfjalj 5y ago

This is the way it's done at many major tech companies. Each individual commit is reviewed then merged directly into main/master. I've never used them but the thought of feature branches seems absurd versus simply merging small changes. Very rarely can a "feature" not be broken down into small self-contained changes.

Starlevel001 5y ago

> Deploy now, catch bugs...sometime, maybe (TM)! Given the state of literally all software I use, this seems to be the default behaviour.

Ozzie_osman 5y ago

I've found that to be a great middle ground on most teams. If you want to stretch it a little more, you could selectively do post-merge reviews for things that might be low risk (ie a UI change that's behind a feature flag that only your team sees), and keep riskier changes (like a big refactor, a data migration, etc) on the pre-merge review flow.

deckiedan 5y ago
We have pre merge review - but for trivial stuff, text / label changes, etc, put a "tiny" tag on the PR, and if urgent paste it to the slack channel asking for a glance and nod review... At least having another pair of eyes check text-only changes has caught so many typos, etc, and only takes a couple minutes.

PontiacParade 5y ago

I agree with the middle ground comment. That is how we tend to do things where I work. We have a modified GitFlow: main: is the source of truth and is what is in production. develop: is the constantly moving branch we make PRs against. You can commit directly here which is discouraged but it isn't a hard rule. ticket: is a branch for each JIRA ticket not each feature. release: We don't make these and just use tags on main. Each "release" is a merge from develop to main and that gets deployed. hot fix: These are made against main and merged back to develop when they are used. It is rare enough I have to look up our "official" procedure. With that we can easily use PRs, release code in small hidden chunks, do code reviews, etc. Seems like the big win they got was releasing small hidden chunks of a feature and deploying it to staging. They also gave up some nice things as well like code review before merging.

chrisweekly 5y ago
Yeah, feature flags are increasingly mainstream / worthwhile, but I hate the idea of giving up on not just CR before merging, but also "preview deploys" (from feature branches to ephemeral deploy envs).
chx 5y ago
For us, whether you commit directly to develop or create a branch is more of a decision whether QA needs to be involved . Once you are done, you merge with squash so develop has no merges and later it's not even visible whether you just committed into develop or worked in a branch. Obviously this might not work if your work involves large changes but we work in tiny bits.
xyzzy_plugh 5y ago
> ticket: is a branch for each JIRA ticket not each feature. This kind of thing really grosses me out. Why can't you just include the issue number in relevant commit messages? Why does it matter what your branches are named? Naming branches relevant to what they actually represent is incredibly important to me, personally. I don't care what you do but I refuse to play by this rule in particular, when it's a hard rule.
- 5y ago

xupybd 5y ago

Context matters. What is the cost of a bug getting into the wild vs what is the cost of keeping the bug rate very low? If you're NASA or a high frequency trading company I'm guessing the cost of bugs can be very high. If you're making internal tools to automate admin tasks the cost of bugs is often very low.

akyoan 5y ago
> If you're NASA I don’t think it's fair to pick something extra-ordinary to respond to the article. Obviously "no worries" doesn't apply if the stakes are high.
- xupybd 5y ago
  I'm not trying to say it's binary. That you're either NASA or your quality doesn't matter. NASA is only the furthest on one end of the scale that I could think of. There is a scale and you have to know where you are. There is always a trade off between the amount of work you can get done and the amount of QA process you have in place. With infinite resources it wouldn't matter but us programmers are expensive.

pcthrowaway 5y ago

I'm guessing this is a reference to "MIME, someday, maybe" - http://1997.webhistory.org/www.lists/www-talk.1993q1/0182.html http://1997.webhistory.org/www.lists/www-talk.1993q1/0182.ht...

shawnps 5y ago

To make this process safer I usually recommend: 1. Put all new code behind feature flags that are off by default in production. 2. Make rolling back easy. 3. Have extensive unit and integration tests. Some of the deployment steps could be automated even further -- maybe the CI server automatically deploys Staging after a successful build. See the books Accelerate: The Science of Lean Software and DevOps, and The Toyota Way for more.

akyoan 5y ago
> Put all new code behind feature flags How is that even possible? A comma change in a feature can break things, are you going to put that change behind a feature flag? "New code" isn't just "new files/functions", so it's not always feasible to keep it behind flags, unless you use a "copy on write" methodology to all code.
- mkdirp 5y ago
  Parent commenter probably meant putting new features behind a flag. I work for a major feature management company and we heavily use our own platform. Yet we don't put "all code" behind feature flags but we do with features. It's nearly impossible to put "all code" behind feature flags.
  - shawnps 5y ago
    Right, basically this. If you're shipping something new that could affect production, put it behind a feature flag so the code paths that are already live are unaffected. Continuously ship small changesets so that it's easy to roll back if necessary.
    - dpark 5y ago
      > If you're shipping something new that could affect production… Which, again, is everything. I’m all for feature flags, but they cover very specific cases. There are many changes that feature flags cannot cover. The addition of the feature flags itself can introduce bugs. They are a great feature but only one small piece of protecting production.

DougBTX 5y ago

Yes, a good middle ground is the slightly confusingly named “GitHub flow”: https://docs.github.com/en/get-started/quickstart/github-flow https://docs.github.com/en/get-started/quickstart/github-flo... The main branch is always stable, releasable. Feature branches are branches off main, which are then merged back into main. No develop or release branches. It is like trunk based development, especially if branches are kept short and regularly rebased onto origin/main, but with a point to run PR checks before merging.

pydry 5y ago
This is how most people I know develop and have done for years but I've never heard anybody ever call it "github flow".
- Traubenfuchs 5y ago
  I also lifted an eyebrow at this. It‘s just „trunk based development with feature branches and prs“.
  - pydry 5y ago
    It reminded me of when Microsoft used to pay people to say "just bing it".
    - the_fury 5y ago
      The term predates the Microsoft acquisition by a number of years.
      - CRConrad 5y ago
        See cousin comment: https://news.ycombinator.com/item?id=29609937 https://news.ycombinator.com/item?id=29609937
- dpark 5y ago
  I think it acquired this name to distinguish from “git flow”, an alternative way to use git that is, put politely, somewhat of a maintenance headache. https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow https://www.atlassian.com/git/tutorials/comparing-workflows/...

teknopaul 5y ago

What's makes you think that just because you code rewiew after it hits trunk that you deploy before review? I think the problem people have with trunk dev is they don't grok that some projects don't have the same deployment strategy as them. There is a thing called a code freeze. This is a common practice. Not everyone does it. Just because you do trunk dev does not mean you can't also have a feature branch to try stuff out or a release branch or any other number of branches. What trunk dev means is get your ode out there to other devs quick. Not necessarily get your code out to production or to QA or the customer quick. Those decisions can be independent of branch strategy.

CRConrad 5y ago
It's easy to confuse continuous integration and continuous deployment because they're so often mentioned in the same breath. Aren't they collectively called "CI/CD"? (Confession: At least I "think* this is an example of getting them confused. They are different things, right...? The same difference you mentioned?)