1st day on the job and I am greeted with EOD, SIT, DEV, UT, POC..
Someone give me an Cheat sheet of this shh...

Dev: write your code here
Sit : test your code here with integrations
UT: user testing? Generally known as UAT
POC: proof of concept? Write your shitty hack job here for demo before Dev.
EOD: Google says it's explosive 😄

EOD: End of the Day (I think).
UT: User/Usability Testing? If it's UAT then it's User Acceptance Testing.
POC: Proof of Concept

SIT? No idea.

STI = Single Table Inheritance — think polymorphism in the DB, allowing for some object oriented nature. The simple: a column points to a class name. Yay!

Dev = Developer, or Development Environment (dev env)

EoD = End of Day

Rest are as stated above.

Never heard of that drugs. I guess they are new

@Root System Integration Testing.

Pre UAT if you have to deal with 3rd party changes.

@C0D4 Aha! So, staging.

@Root @C0D4 fuck me if I’m wrong, but isn’t staging just before prod.

As in:
1. dev tests locally if possible(after its unit tests)
2. Integration Test (we used to call it TnI env: for test and integration)
3. UAT env, for the user/ broader community to test with mock data
4. Staging: same as UAT but with prod-near data, on similar servers to have the same configs and sort of a stress test
5. Production

@dder Honestly, it varies by company, and the names can vary too.

At my employer, we deal with PII (personally identifiable information, CC numbers, SSNs, etc.), and there are extremely strict rules on who can read and write to this data, where it can be stored (even encrypted), how it can be transmitted, etc. so our testing/deploy setup is a little different.

We have semi-prod servers that have fake data, and semi-prod servers with real prod data (but severely limited/redirected communication). Both of these are for testing. The reason for using real data is because it always contains bizarre edge cases (and errors...) that generated data will not. It is from the wilds, after all.

So:
• Dev/local
• UAT
• staging (used for e.g. release building, sales/feature demos)
• sandbox (clients have access)
• semi-prod with fake data
• semi-prod with real prod data
• production

In general, though, I believe you are right. Staging usually falls right before prod, and is used for pre-release testing.

I would call my employer’s “staging” environment “integration” because its purpose is to integrate the various feature branches. (“Sandbox” also fits, though that insinuates playing, and that’s what we encourage the clients to do!)

@dder as @root said its company dependant.

For us it's

- Dev: sandbox with no data, you need to mock it yourself

- SIT: sandbox with minimal functional data but things like customers, orders, etc is missing but connects to 3rd party systems

- UAT: full copy of prod to handle full user testing (however customer data like emails are changed to prevent obvious issues there)

- Staging: another full copy of prod if required, think big project / waterfall release to ensure we have the prod deployment down pack

- PROD

@C0D4 @Root
Alright, fair, quite naive of me to think that there is a common base between companies. I agree, it’s dependent on the pipeline and what’s in there.

But actually, that severs as a perfect example for @NoobAndroidDev . That all that stuff is different and matter of interpretation.

@C0D4 going to print this on a piece of paper and keep it for reference 😂😂