4 ms·

In real world software dev, I fail to see how a release branch is a flaw. It’s completely reasonable to want to test something in a “gold-master” state before s

by crgwbr 7y ago

In real world software dev, I fail to see how a release branch is a flaw. It’s completely reasonable to want to test something in a “gold-master” state before shipping it to prod. Regardless of how many tests you have, that’s just a good idea.

dhimes 7y ago
Yeah it's what we call staging. I have a project now that doesn't have a staging environment that's well integrated and it's very nerve-racking. I use hg but it's the same idea.
- ulisesrmzroche 7y ago
  Staging corresponds to master, tags are branches.
  - dhimes 7y ago
    We have a branch called “live”. That’s on our production server. Staging is testing to make sure our dev is worthy of moving to live.
ulisesrmzroche 7y ago
That’s what versión tags are for. Plus real world software development, what does that mean? Just say it straight up: you don’t think I have a real job
- crgwbr 7y ago
  No, that's not what I meant and I apologize if it came across that way. What I meant was, it's easy to think of an idealized world where a everything has test suites with 100% branch coverage, complete e2e tests, automated screenshot tests of the UI, etc. But, in the real world, that most often isn't true. I've been on a lot of teams. Lots of legacy code has no automated tests at all. Lots of modern code has decent unit test coverage, but nothing for the UI. These are cases necessitating a manual testing step before releasing to prod, and manual testing will often uncover bugs that need fixed. Thus, you need to be able to fix these and continue testing, all the while having as little impact as possible on other Devs working on things unrelated to this release. Having either a single long-lived release/QA branch or shorter-lived release-specific branches accomplishes this in a reasonably simple way. That's what I meant by real-world software development. If you work at a shop with an amazing test suite and don't need these steps, good for you. But, in my 15 years of development, I've never seen a shop like that.

by crgwbr 7y ago

dhimes 7y ago

Yeah it's what we call staging. I have a project now that doesn't have a staging environment that's well integrated and it's very nerve-racking. I use hg but it's the same idea.

ulisesrmzroche 7y ago
Staging corresponds to master, tags are branches.
- dhimes 7y ago
  We have a branch called “live”. That’s on our production server. Staging is testing to make sure our dev is worthy of moving to live.

ulisesrmzroche 7y ago

That’s what versión tags are for. Plus real world software development, what does that mean? Just say it straight up: you don’t think I have a real job

crgwbr 7y ago
No, that's not what I meant and I apologize if it came across that way. What I meant was, it's easy to think of an idealized world where a everything has test suites with 100% branch coverage, complete e2e tests, automated screenshot tests of the UI, etc. But, in the real world, that most often isn't true. I've been on a lot of teams. Lots of legacy code has no automated tests at all. Lots of modern code has decent unit test coverage, but nothing for the UI. These are cases necessitating a manual testing step before releasing to prod, and manual testing will often uncover bugs that need fixed. Thus, you need to be able to fix these and continue testing, all the while having as little impact as possible on other Devs working on things unrelated to this release. Having either a single long-lived release/QA branch or shorter-lived release-specific branches accomplishes this in a reasonably simple way. That's what I meant by real-world software development. If you work at a shop with an amazing test suite and don't need these steps, good for you. But, in my 15 years of development, I've never seen a shop like that.