4 ms·

Maybe I'm missing something here, but I haven't worked anywhere for years that's had a "staging" environment, as least not as this article describes it. Everyw

by kypro 4y ago

Maybe I'm missing something here, but I haven't worked anywhere for years that's had a "staging" environment, as least not as this article describes it. Everywhere I've worked either has spin up environments, a developer issued test environment or various lower testing environments where we can deploy individual features for testing and QA. But more to the point everywhere I've worked has also combined these lower level testing environments with some kind of pre-production environment which features more data (typically a clone of prod). On this environment often a further layer of tests are ran and new features are manually reviewed one last time before being deployed to production. Where does a "staging" environment fit in this? Unless I'm miss understanding the article seems to suggest code goes, dev -> staging -> prod, but aside from one developer role I had in the early 00s it's always been, dev -> test env -> pre-prod -> prod. Is the article suggesting you can just do away with pre-prod environments for "preview" environments? And why would you even want to do that? As I understand it one of the features of a pre-prod environment is that is persists and isn't a clean slate each time. Any mess that can accumulate in prod can accumulate in a pre-prod environment. I guess I'm not following what this article is advocating for.

pbalau 4y ago
pre-prod is staging.
- pmontra 4y ago
  Not always. Not every company likes continuous deployment. Sometimes staging is the server that demonstrates the feature of the day or of the week. Preprod is where all the software goes after getting a green light in staging, waiting to go in production maybe a few times per month or even per year.
ezekg 4y ago
> But more to the point everywhere I've worked has also combined these lower level testing environments with some kind of pre-production environment which features more data (typically a clone of prod). On this environment often a further layer of tests are ran and new features are manually reviewed one last time before being deployed to production. Sounds like staging to me...
- maerF0x0 4y ago
  fwiw it's generally not compliant to copy prod data into an alternative env without doing major scrubbing. Else your preprod env now has to have SOC compliance things like auditing of access to DBs, GDPR deletion etc.
  - ryanSrich 4y ago
    > fwiw it's generally not compliant to copy prod data into an alternative env without doing major scrubbing. Else your preprod env now has to have SOC compliance things like auditing of access to DBs, GDPR deletion etc. Which it absolutely should. If the idea is to go from your local environment with test data, to some staging or pre-prod environment in the cloud with (potentially) prod data. Then that cloud environment (regardless if it's called staging or pre-prod, or if it houses prod data or not), should be an exact replication of your production environment. Down to every detail.
    - jcraft 4y ago
      If the data contains sensitive information about individuals (PII), you can't replicate that across all environments if you're in a regulated industry. There are ways to anonymize the data, eliminating the PII risks while preserving data utility so testing is accurate.
      - ratorx 4y ago
        Anonymisation has always seemed to me to be a reduction in the probability of exposure rather than a complete guarantee of safety. Arguably you should need compliance on both staging and prod, but you do the anonymisation to reduce the risk of exposure from (less tested) code in staging. I’ve always viewed staging as the environment that gets prod data (maybe anonymised), but has ideally no exposure to actually affecting prod, rather than a completely fake environment.
      - ryanSrich 4y ago
        Well, you can, but you need to ensure every environment to which it’s replicated is also compliant. That’s my entire point.
ryanSrich 4y ago
> dev -> staging -> prod > dev -> test env -> pre-prod -> prod You're just using a different word and adding one additional environment. You swapped out the word staging and replaced it with pre-prod.
phphphphp 4y ago
"Staging" means "an environment where multiple unreleased pieces of work are tested together before being released to production". Pre-prod and staging are synonymous in most organisations. A preview environment is an ephemeral environment for testing a single piece of unreleased work. Framing it according to the terms you've used, the article is advocating for replacing "dev -> test env -> pre-prod -> production" with "dev -> test env -> production".
- kypro 4y ago
  Thanks for clarifying. In that case what they're advocating for seems like a really bad idea. One nice thing about having staging / pre-prod environment is that it can replicate prod architecture, content and config (for the most part anyway) which allows for things like performance checks to be ran after code has been tested for functionality in lower environments. Something I've also seen is that prod websites typically load various analytic and marketing scripts which might not be included on dev environments. Even if those scripts are not maintained by the dev team, you probably still want to be checking any code being deployed isn't going to break an analytic script because it's expecting links to have a certain class, etc.
pmontra 4y ago
The article is about spinning up multiple staging servers, maybe one per branch/feature and possibly leaving them there for hours or days, to be inspected at each own URL until somebody confirms that the implementation is OK. All of this is automated (a git push?) The usual staging and/or preproduction environments would be the preview of their own branches. It sounds nice. The only problems I can see are: 1) The cost, because each one of those instances could have its own queues, databases, connections with third party APIs, etc. 2) Seeding the database with a meaningful amount of data. I often see preproduction database built by testers month by month after a minimal seeding. Each instance here has to be seeded with all data plus what's required to demo the new feature. That must be saved before destroying the database, reused for further branches, merged with the data for other features.
- jcraft 4y ago
  There are ways to anonymize production data and make it available in preview and testing environments. My company has been doing that for customers and it has been effective. You get privacy-safe data that is still very close to production data. Depending on the application architecture, you can spin up database containers and seed them with replicas of the anonymized data.
nunez 4y ago
staging goes by a lot of different names, most commonly UAT, pre-prod or Acceptance it's the place where more biz-facing people can tell you the color's off by like half a shade just before a big release :)

by kypro 4y ago

pbalau 4y ago

pre-prod is staging.

pmontra 4y ago
Not always. Not every company likes continuous deployment. Sometimes staging is the server that demonstrates the feature of the day or of the week. Preprod is where all the software goes after getting a green light in staging, waiting to go in production maybe a few times per month or even per year.

ezekg 4y ago

> But more to the point everywhere I've worked has also combined these lower level testing environments with some kind of pre-production environment which features more data (typically a clone of prod). On this environment often a further layer of tests are ran and new features are manually reviewed one last time before being deployed to production. Sounds like staging to me...

maerF0x0 4y ago
fwiw it's generally not compliant to copy prod data into an alternative env without doing major scrubbing. Else your preprod env now has to have SOC compliance things like auditing of access to DBs, GDPR deletion etc.
- ryanSrich 4y ago
  > fwiw it's generally not compliant to copy prod data into an alternative env without doing major scrubbing. Else your preprod env now has to have SOC compliance things like auditing of access to DBs, GDPR deletion etc. Which it absolutely should. If the idea is to go from your local environment with test data, to some staging or pre-prod environment in the cloud with (potentially) prod data. Then that cloud environment (regardless if it's called staging or pre-prod, or if it houses prod data or not), should be an exact replication of your production environment. Down to every detail.
  - jcraft 4y ago
    If the data contains sensitive information about individuals (PII), you can't replicate that across all environments if you're in a regulated industry. There are ways to anonymize the data, eliminating the PII risks while preserving data utility so testing is accurate.
    - ratorx 4y ago
      Anonymisation has always seemed to me to be a reduction in the probability of exposure rather than a complete guarantee of safety. Arguably you should need compliance on both staging and prod, but you do the anonymisation to reduce the risk of exposure from (less tested) code in staging. I’ve always viewed staging as the environment that gets prod data (maybe anonymised), but has ideally no exposure to actually affecting prod, rather than a completely fake environment.
    - ryanSrich 4y ago
      Well, you can, but you need to ensure every environment to which it’s replicated is also compliant. That’s my entire point.

ryanSrich 4y ago

> dev -> staging -> prod > dev -> test env -> pre-prod -> prod You're just using a different word and adding one additional environment. You swapped out the word staging and replaced it with pre-prod.

phphphphp 4y ago

"Staging" means "an environment where multiple unreleased pieces of work are tested together before being released to production". Pre-prod and staging are synonymous in most organisations. A preview environment is an ephemeral environment for testing a single piece of unreleased work. Framing it according to the terms you've used, the article is advocating for replacing "dev -> test env -> pre-prod -> production" with "dev -> test env -> production".

kypro 4y ago
Thanks for clarifying. In that case what they're advocating for seems like a really bad idea. One nice thing about having staging / pre-prod environment is that it can replicate prod architecture, content and config (for the most part anyway) which allows for things like performance checks to be ran after code has been tested for functionality in lower environments. Something I've also seen is that prod websites typically load various analytic and marketing scripts which might not be included on dev environments. Even if those scripts are not maintained by the dev team, you probably still want to be checking any code being deployed isn't going to break an analytic script because it's expecting links to have a certain class, etc.

pmontra 4y ago

The article is about spinning up multiple staging servers, maybe one per branch/feature and possibly leaving them there for hours or days, to be inspected at each own URL until somebody confirms that the implementation is OK. All of this is automated (a git push?) The usual staging and/or preproduction environments would be the preview of their own branches. It sounds nice. The only problems I can see are: 1) The cost, because each one of those instances could have its own queues, databases, connections with third party APIs, etc. 2) Seeding the database with a meaningful amount of data. I often see preproduction database built by testers month by month after a minimal seeding. Each instance here has to be seeded with all data plus what's required to demo the new feature. That must be saved before destroying the database, reused for further branches, merged with the data for other features.

jcraft 4y ago
There are ways to anonymize production data and make it available in preview and testing environments. My company has been doing that for customers and it has been effective. You get privacy-safe data that is still very close to production data. Depending on the application architecture, you can spin up database containers and seed them with replicas of the anonymized data.

nunez 4y ago

staging goes by a lot of different names, most commonly UAT, pre-prod or Acceptance it's the place where more biz-facing people can tell you the color's off by like half a shade just before a big release :)