What are environments, anyway?
Most software companies have their product deployed to a few different environments, which have names lik...
For further actions, you may consider blocking this person and/or reporting abuse
Excellent break down of environment usage. I'd like to note that different organizations have different name for each stage/s, however, the reasoning is still valid.
Some example
DEV -> INT -> SIT -> UAT -> PRD
LCL -> UAT -> PRD
LCL -> Staging -> Blue || Green PRD
Do not get caught up on the names, enforce separation of concern and responsibility.
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.
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.
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.
...Unless you've in a marketing agency where the idea of a "planned release" goes straight out the window.
Great post!
I am new to these concepts and I like to know some things!
Each enviroment (dev, test, stage) is a different computer (with its own database, its own code)?
Can I use a docker container for each of these envs?
If I use docker, can I use differents env in ONE docker container? Or I have to separate in several containers?
Sorry if the question are dumbs!
Thank you very much!
Hi Germán! Great questions.
Not necessarily. More than one environment could coexist on the same computer, but they'd need some separation (code in different folders, served on different ports if it's a web app).
Sure, there's no reason why you couldn't.
I don't know enough about docker to answer that one. I think it would difficult to configure like that, since you want the environments to act independently of each other.
This is all very true... unless you're embracing continuous deployment, in which case deploying straight to production is a core feature and a huge benefit.
Interesting, I've never been on a team that practiced continuous deployment. A few questions: Where does QA fit in? What about automated tests? How do you maintain confidence in your changes? How do you handle large, cross-team feature development? In your experience, does it work as well as as a multi-stage release cycle?