"Everybody has a testing environment. Some people are lucky enough enough to have a totally separate environment to run production in"
Ha! Love it.
Testing on production
11–20 of 101 posts
Re: Testing on production
#12"Everybody has a testing environment. Some people are lucky enough enough to have a totally separate environment to run production in"
I code at the interface between ops teams (on the business side) of companies and dev teams (on the IT side).
One of the things I've realized is that in most unregulated companies (read: non-healthcare/financial) the business side of the house is used to having little or no lower lifecycle.
If they want to make a process change, they make it on production work.
Granted, they have change control approvals, etc. etc., but the whole dev-test-prod cycle looks extremely different for them, because you can't do certain things without lower environments.
Re: Testing on production
#13Good article, but it's a bit binary on the notion of incident. For the same company, it can be very serious to have a global 1h outage, but not so serious to have the internal admin interface down for 1h. This allows for more fine-grained assessment of the validation required to push to prod: the "checks" only have to test the critical part of the application. Dev exp start deteriorating when the non-critical parts are over-tested.
Re: Testing on production
#14> The TL;DR is that some (“best”) practices are contextual and understanding when to use them is ultimately what gives us the title of “engineers”.
So well put, just today I implemented a feature and kept asking myself if i should be extending the component (leaning more towards OOP) or just add an additional argument to said component. The latter would have stuck more with the current style but I also realized there's no obvious better way, extending made sense and I realized the importance of understanding the nuance and standing up for those design decisions is what I am here to do :)
thank for putting that in less words
Re: Testing on production
#15I don’t understand why people redefine words just make their point. It can be confusing at best and at worst change the me meaning of words when it becomes viral. “Smart” people means smart people. It shouldn’t be used to mean junior dev who are trying to hard to prove themselves and over engineer or choose the wrong approach. So many words have changed their original meaning because someone decides to write a viral…
Oh right, the "original meaning" of "smart"... so you must mean "pain or ache"? I really don't see how that's relevant to the article.
Words change, they always have, they always will. Get over it.
And anyway, the article's usage is consistent with the well-established phrase "smart guy", within which the word "smart" carries a sarcastic and derisive tone.
Re: Testing on production
#16Good article, but it's a bit binary on the notion of incident. For the same company, it can be very serious to have a global 1h outage, but not so serious to have the internal admin interface down for 1h. This allows for more fine-grained assessment of the validation required to push to prod: the "checks" only have to test the critical part of the application. Dev exp start deteriorating when the non-critical parts a…
Yes criticality is multidimensional, this was a simplification for the sake of brevity. Will add a note. Thank you!
Re: Testing on production
#17Just keep the enironments separate, but similar. What works in the test environment, should work in production.
Of course, there are always exceptions to this rule. Adapt and modify the code as needed.
We keep three environments at work: Dev, Test and Prod. However, dev environments are sometimes neglected and some features land in Test only.
So, use Dev as a development playground. Use Test to test the changes made in Dev. If the change is approved in Test, it will go in Prod environment.
Re: Testing on production
#18An interesting perspective I once heard from an information security expert is that there's a difference between risks and 'things that can go wrong'. Something is only an actual risk if it hurts the bottom-line. In particular quite a few things that can go wrong don't carry that much risk, and conversely something that is hard but not impossible to go wrong may carry huge amounts of risk.
The trick with this perspective is that after identifying the real risks you can then link the risks and possible mitigations by looking at all 'things' and identifying the ways in which they might fail (and how this may be prevented from happening). This way you can easily identify which mitigations are helping prevent risks and which risks are not sufficiently mitigated. It's a fair bit of work, but it's not complicated and often gives useful insights.
What this article basically does is note that you should first asses what risks a failed deployment has, and correctly states that in quite a few cases this risk is low and therefore the mitigations (of which there can be many) may not be necessary and may in fact be doing harm without actually sufficiently preventing any risk.
Re: Testing on production
#19"Everybody has a testing environment. Some people are lucky enough enough to have a totally separate environment to run production in"
That should honestly be the norm at any larger company.
Even at startups, the added initial costs yield more long term benefits with higher-quality products.
Re: Testing on production
#20I have a dumb question as a non-SWE who is curious about software engineering.
I've heard "feature flags" are popular these days, and I understand that that's where you commit code for a new way of doing things but hide it behind a flag so you don't have to turn it on right away.
Now, if I want to test in prod, couldn't I just make the flag for my new feature turn on if I log in on a special developer test account? And if everything goes well, I change the condition to apply to everyone?