Our team uses feature branches instead of committing to master, so the idea of "Dev should auto-deploy from the master branch every time there are new commits" is odd to me. But like was mentioned in another comment, applying the concepts in this article just means that we may have multiple dev environments: one for each feature branch.
About the Test and Stage environments...
Why is Stage the last line against bugs? The QA team works with the test environment. How will bugs be caught in Stage?
Similarly, only Stage was mentioned to have a Production-like database backing it. However, in my experience, many unexpected defects come from how the code interacts with odd production data. So the production-like data of Stage is crucial for catching bugs.
I've been a professional C, Perl, PHP and Python developer.
I'm an ex-sysadmin from the late 20th century.
These days I do more Javascript and CSS and whatnot, and promote UX and accessibility.
It's odd to me too. I'm more used to master representing production, and the test environments tracking a release branch. But the principle of separation is basically the same.
I'm a big believer in feature branches, though at some point they have to be merged into a master or dev branch, right?
I glossed over this, but although the QA team focuses on the Test environment, they should definitely spend some time vetting Stage before it goes to Prod. I agree that Production data is often wilder and weirder than test data, so testing against it can (depending on the product) be crucial to catching bugs. I worked at one place where every database (all the way down to developers' own local databases) would get refreshed with data from Production a few times per month. That introduced some overhead, but it was often helpful.
I agree with you, my organization recently had a problem that I think it could have been solved with a release branch, the problem now is that we need to integrate a new infrastructure and at leas in my company it is a big deal.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Good breakdown, thanks for writing this.
Our team uses feature branches instead of committing to master, so the idea of "Dev should auto-deploy from the master branch every time there are new commits" is odd to me. But like was mentioned in another comment, applying the concepts in this article just means that we may have multiple dev environments: one for each feature branch.
About the Test and Stage environments...
Why is Stage the last line against bugs? The QA team works with the test environment. How will bugs be caught in Stage?
Similarly, only Stage was mentioned to have a Production-like database backing it. However, in my experience, many unexpected defects come from how the code interacts with odd production data. So the production-like data of Stage is crucial for catching bugs.
It's odd to me too. I'm more used to master representing production, and the test environments tracking a release branch. But the principle of separation is basically the same.
I'm a big believer in feature branches, though at some point they have to be merged into a master or dev branch, right?
I glossed over this, but although the QA team focuses on the Test environment, they should definitely spend some time vetting Stage before it goes to Prod. I agree that Production data is often wilder and weirder than test data, so testing against it can (depending on the product) be crucial to catching bugs. I worked at one place where every database (all the way down to developers' own local databases) would get refreshed with data from Production a few times per month. That introduced some overhead, but it was often helpful.
I agree with you, my organization recently had a problem that I think it could have been solved with a release branch, the problem now is that we need to integrate a new infrastructure and at leas in my company it is a big deal.