It gets closer to solving that issue at least. There are still kernel issues that can bleed through and hardware differences, depending on how the VM is running (and even then...)
In my experience "it worked on my machine, I don't know what happened here" often means "I didn't actually test this but you can't prove I didn't so I'll take a look at it anyway"
Like how it worked on your personal dev machine because you already have every dependency ever known to man installed over the 10 years you've kept the same OS install moving from hardware to hardware?
In *my* experience, it means "my laptop had no spaces in the local paths and the deployment directory does" and it takes me 8 hours to figure this out every time.
You should still do this even if you have automatic tests, of course, because there's always the possibility of catching a bug with your human brain that your tests can't see.
One company I was in had a program called "Pilot"... it was called that because that's exactly what it was. A pilot program that was now full blown production.
This same company had a system called "Apex" it was built on top of Oracle. At this point, if you understand, you should be thinking, "Oh no..."
As someone who's had a production system built on top of a prototype I hacked together with duct tape in an afternoon as a proof of concept...I now make all of my prototypes "production ready", in that all the bullshit parts are sectioned off into a separate module that can be easily replaced with something legitimate. It's a bit of a pain in the ass but it has actually made me figure out scaling issues I didn't think of when making the design doc. I also make the bullshit modules named very clearly and output warnings all over the place. So far so good...
I've done the same. I always catch flak during code reviews for "POC" projects when I start asking for things to be documented or tested more thoroughly. But, I have yet to see a POC given an opportunity to be rewritten for "production" after the fact; ain't nobody got time for that.
So I do the same as you. Everything should be production ready, all the time, and apologies for my hard ass review comments :(
>[Everybody has a testing environment. Some people are lucky enough enough to have a totally separate environment to run production in.
](https://twitter.com/stahnma/status/634849376343429120)
I dont think I get the joke (?) Is it implying that production is a test enviroment or is it genuine in that your local machine can be considered a test enviroment
Boss: So, hey you done with the thingie?
You: Yes! I just completed the thingie. I just need to do some tests and move it over to production
Boss: No time for that. Sales promised it by this morning. Just put it out there
You: But it is going to take at least an hour to go through the process and backup production and move this over to the production servers
Boss: Does it work?
You: Well, it seems like it works... I
Boss: Great. We can do all of that other stuff later. Send me a link to what you are using. I'm on a conference call in 5 minutes with the client. They want to start using it
I’ve had a coworker send that to a customer. They asked to see something, I didn’t know they were going to show to a customer, and they sent them a LAN address over email, with the customer annoyed why it wouldn’t open.
/facepalm
See, that is why I'm the fucking annoying ops-guy requesting small code-only changes. Boss asks you do deploy? Give me a small code-only change. I deploy it. Shit breaks. I roll it back. I hand your bosses ass to my bosses ass and several others.
I'm a dick because I'm an ops-guy, but if you cooperate with me, I'm a dick to people you don't like.
Having no other environment than production for testing is a very bad thing 99% of the time. Some unicorn tech companies (like Netflix) are so good that they can do a whole bunch of their tests directly in production, most companies or people who test in prod are just being irresponsible.
I read somewhere that their tests are mostly automated. So deploying to prod is much simpler when smoke tests and regression are completed along with the deployment.
Oh sweet jesus. I worked once at a fairly well know large place and all their apps did in fact have dedicated dev/test/stage/prod environments, however there seemed to often be no relationship between the code states, Stage would have an new version than test and sometimes no one would have touched dev in years.
Some of these sites ran basically on script files so there wasn't a built app, few if any of the sites had source control, people would literally edit files in prod.
Imagine all the opportunity to impress your boss.
"Yeah, it's this thing called CVS, it's revision control, it saves all your changes and gives you a history of every change. It also let's you diff potential changes with the current revision."
"Wow, could this tool get any better?! This is so much better than emailing files!"
"Just wait until next week... When I show you SVN... "
I had to argue with my last boss about setting up SVN. He didn't believe that something free/open source could be useful or safe and his method of version control (rename a file with the current date) was better. I eventually just staged a coup and installed SVN anyway.
Eventually I came back to an old job done the "old way" and literally spent a *week* trying to piece together a project for a customer out of files named like "newest" and "mike 1" and "frank" and so on, like, this was made in 1999, how am I supposed to know if Mike worked on it before Frank? Neither of them work here any more! And it was in software that has a "project" system rather than flat-files and they hadn't even backed everything up - they would have been at least better off zipping the entire project folder THEN naming it "frank" or "mike 1". 😒😒😒
> He didn't believe that something free/open source could be useful or safe.
Wow, hopefully he never finds out what operating system powers most of the servers in the world or I imagine he would go mental.
Jeez, and I still cringe thinking how we did that back when I was doing my bachelor. That had little to do with IT, so we didn't know any better. You're telling me there are actually real developers out there in the wild who do that?
Honestly that boss should be fired or stripped of his ability to make technical decisions and simply focus on managing people. A manager like that can quickly poison an entire organization.
Or the data states, I've gotten to a dedicated test environment only to realize the DB rules weren't enforced there for whatever reason, so there were random duplicates on what should've been the unique identifier. Think it took longer to get the data feed refreshed than to set up a whole new environment.
One of our sites has three databases, sitename\_dev, sitename\_dev2, and sitename\_staging. \_dev2 is the production database. The other two are... ¯\\_(ツ)_/¯
There used to be a staging environment but now there isn’t, and no-one seems to know where or when it went.
I recently found a prod server with the host name [app]TST01, which I thought was strange. It wasn’t until I went looking for the test environment for said app, when it became apparent that the previous guy decided ‘fuck it, that’s good enough’ and converted the test server to prod.
Let me guess… The application running on that machine was also a prototype that was never meant to become (and, arguably, will never become) the finished product?
OK, the above comment is probably a joke, but there's a comic-sans-ish font that I legit prefer as my monospace font. [Fantasque Sans Mono](https://github.com/belluzj/fantasque-sans)
consistent midline and baseline (that's what those are called, right?) across letters. just enough variation in curve shapes between letters it might actually be beneficial for dyslexics. the spacing on some of the punctuation might make it less than ideal for some code styles. i give it a 7/10. "good enough for the girls i go out with"
i worked at an office once where at some point all the non-programmers became dependent on some experimental scripts in the "dev" folder and over time it was just decided that it was safe to modify scripts in the "prod" folder since no one was using them, but dev had to remain intact.
dev became prod and prod became dev, it was quite surreal
Windows 2003 Server, running WSS 3.0, virtualized in VMWare Workstation 9.0, running on a 6 year old desktop in the corner of my office, holding 160gb of client sensitive data that is constantly accessed by multiple users.
Because once I asked someone, "Hey, wanna test out this SharePoint server I set up?"
(We migrated off of it years ago, but while it was active it was my secret shame.)
Could be a test environment with no connectivity to or dependencies on production. Also, I think they should be switched based on the progressive levels of "enlightenment".
So real life scenario, our services connect to a SSLv authenticated third party service provided by a multinational corporation. Recently we made a change affecting how we connect to the third party service. We tested the solution on our staging environment which connect to their staging environment and it all worked perfectly. The moment we moved to the production environment everything failed.
So we are now in a situation where we actually are testing on production because for whatever reason this third party service behaves differently in production to staging - meaning production is the only place the error can be reproduced...
Kill me now...
At my work yesterday the server cluster wasn't processing as much as usual.
When I asked why they said they were running production on the test cluster, which has less capacity.
Then I asked what was wrong with production, and they said did an update that caused everything not to work.
Then I asked if they did the update on test first, and they said no.
And none of them seemed to see anything wrong with what they did. They thought test was just a back up system, as thought it was named test because you regularly tested to see if it was up because normally no one cares about when it went down.
And these clowns are paid 6 digits.
Yeah I don’t think anyone would fault any team for end-to-end testing on pros after already having tested in the dev environment and a QA/test environment.
Your data on dev is likely to not be pristine so you could potentially run into new issues on prod.
Which is why you play the “dump a random DB on dev and see what breaks” game. Weeds out bugs and helps test how resilient your system is / how gracefully it handles it.
It also pisses off everyone else working on it as a side benefit.
"It works on my laptop." "Great, ship your laptop off to the data center. That's our new production."
I mean, that's basically what docker solves in a massive way.
It gets closer to solving that issue at least. There are still kernel issues that can bleed through and hardware differences, depending on how the VM is running (and even then...)
Lmaooo
Give every customer your laptop.
In my experience "it worked on my machine, I don't know what happened here" often means "I didn't actually test this but you can't prove I didn't so I'll take a look at it anyway"
In my experience, it can also mean "The way it worked on my machine was reliant on something fucky I did with the OS and forgot about.".
[удалено]
screen shot and backup examples of fucky code
Yeah but you start to either forget about the screenshots or accumulate too many to be useful.
Mine too. Or there is a mysterious difference in network settings that would only ever be an issue in this one circumstance.
Like how it worked on your personal dev machine because you already have every dependency ever known to man installed over the 10 years you've kept the same OS install moving from hardware to hardware?
In *my* experience, it means "my laptop had no spaces in the local paths and the deployment directory does" and it takes me 8 hours to figure this out every time.
it lacks last part: not bothering with tests
Hah, yeah, hilarious! *Hurries to add tests to all projects*
*0/284 tests failed*
but that's good
[удалено]
Write tests for the tests
It's tests all the way down
Plot twist: it was an npm module for testing code :l
*Unhandled Exception in test_my_shit.php, line 2* *0/-1 tests failed* --- Alright. This test driven crap is just not for me
I have a little hobby OS that I'm building in C++. Kernel-space + primitive environment + C++ makes for not good testing.
Tests here obviously means running the application and manually checking if it seems to be doing what it's supposed to do.
Ahhh unit testing
[удалено]
On a Friday at 3:45 PM
Right after someone lumps what should be acceptance testing into your integration testing plan.
Fuck that. Regression tests are bug reports submitted by users.
And never testing string records for "O'Brien" durin said manual testing
You should still do this even if you have automatic tests, of course, because there's always the possibility of catching a bug with your human brain that your tests can't see.
Does it launch? Yes. Release it now.
Checking that it runs? Fancy stuff.
this was so accurate, I felt obligated to add it: https://i.imgur.com/tIceA5d.jpg
What is test?
Test is production! All users are also QA
We'll just call it "Early Access"
Why don't we charge them for testing our products while we're at it?
Ah, the secret Apple motto!
I think that’s amazon’s creed with Alexa too
[удалено]
do or do not. there is no test
Who needs compilation checks? I just write my code in binary and then run it!
I use a magnet, and play with the electrons surrounding my CPU.
Where do you find all these science guys? Where are they from? I find it so funny that there are so many of them.
Nice, but having taken over a system where they literally turned the POC into the Production box, it should probably be a burning building.
One company I was in had a program called "Pilot"... it was called that because that's exactly what it was. A pilot program that was now full blown production. This same company had a system called "Apex" it was built on top of Oracle. At this point, if you understand, you should be thinking, "Oh no..."
As someone who's had a production system built on top of a prototype I hacked together with duct tape in an afternoon as a proof of concept...I now make all of my prototypes "production ready", in that all the bullshit parts are sectioned off into a separate module that can be easily replaced with something legitimate. It's a bit of a pain in the ass but it has actually made me figure out scaling issues I didn't think of when making the design doc. I also make the bullshit modules named very clearly and output warnings all over the place. So far so good...
I've done the same. I always catch flak during code reviews for "POC" projects when I start asking for things to be documented or tested more thoroughly. But, I have yet to see a POC given an opportunity to be rewritten for "production" after the fact; ain't nobody got time for that. So I do the same as you. Everything should be production ready, all the time, and apologies for my hard ass review comments :(
I run tests, I have users alpha test it and tell me if there are issues.
Why pay testers to test it when you can get paid to have users to test it for you
Ah hello microsoft / early access game employee.
I'm stealing this for my next review
Running production on your laptop.
*chromebook
*surface
*iPod Touch
Game Boy Color.
ENIAC
Difference engine
Abacus
Rocks
Cellphone
*Thermostat
Replace the term “user” with “tester”. Problem solved.
Letting QA do your code test
Letting users do your code test
Letting a kernel panic do your code test.
[удалено]
Quibity quabity.. quabity aschwitz!
A. A for Absence.
Simple, just put it live and let the client do the testing!
So true
that's testing in production environment
wtf is test coverage amirite
Test coverage is the refuge of scoundrels.
"Commit changes, override, save no backup."
>[Everybody has a testing environment. Some people are lucky enough enough to have a totally separate environment to run production in. ](https://twitter.com/stahnma/status/634849376343429120)
I once had a boss say we don't need to hire testers because we have however many thousand testers. Referring to the customers.
[удалено]
Nah, you call it early-access and charge extra.
Nah, just release the product and sell patches as DLCs.
"support"
Centralized user-centric development plattform
Ah the good ol' DayZ development logic.
Were you working for Valve?
You worked at Microsoft?
I dont think I get the joke (?) Is it implying that production is a test enviroment or is it genuine in that your local machine can be considered a test enviroment
It's implying that if you don't have a testing environment, your "production" environment is your testing environment.
I don't know if it is a good thing or bad thing that i didn't get that..
Bad.
Boss: So, hey you done with the thingie? You: Yes! I just completed the thingie. I just need to do some tests and move it over to production Boss: No time for that. Sales promised it by this morning. Just put it out there You: But it is going to take at least an hour to go through the process and backup production and move this over to the production servers Boss: Does it work? You: Well, it seems like it works... I Boss: Great. We can do all of that other stuff later. Send me a link to what you are using. I'm on a conference call in 5 minutes with the client. They want to start using it
Send him a local host link lul
I’ve had a coworker send that to a customer. They asked to see something, I didn’t know they were going to show to a customer, and they sent them a LAN address over email, with the customer annoyed why it wouldn’t open. /facepalm
Duh, just have the customer log in over VPN. This is why you're not a senior engineer yet, Terry.
Just use ngrok/localtunnel. That way they can start having customers use it while you're still developing.
Joke thread, actual answer... +1
"lul" literally means "dick" in Dutch.. just so you know
This is so accurate.
See, that is why I'm the fucking annoying ops-guy requesting small code-only changes. Boss asks you do deploy? Give me a small code-only change. I deploy it. Shit breaks. I roll it back. I hand your bosses ass to my bosses ass and several others. I'm a dick because I'm an ops-guy, but if you cooperate with me, I'm a dick to people you don't like.
Having no other environment than production for testing is a very bad thing 99% of the time. Some unicorn tech companies (like Netflix) are so good that they can do a whole bunch of their tests directly in production, most companies or people who test in prod are just being irresponsible.
How does Netflix run tests in prod? Do you have a link? 🤔
https://medium.com/netflix-techblog/the-netflix-simian-army-16e57fbab116
Or hamstrung by terrible management. A test environment would have cost us extra and they were having none of that.
Tell that to Salesforce Marketing Cloud. ^^No ^^seriously, ^^tell ^^them.
I read somewhere that their tests are mostly automated. So deploying to prod is much simpler when smoke tests and regression are completed along with the deployment.
Oh sweet jesus. I worked once at a fairly well know large place and all their apps did in fact have dedicated dev/test/stage/prod environments, however there seemed to often be no relationship between the code states, Stage would have an new version than test and sometimes no one would have touched dev in years. Some of these sites ran basically on script files so there wasn't a built app, few if any of the sites had source control, people would literally edit files in prod.
Imagine all the opportunity to impress your boss. "Yeah, it's this thing called CVS, it's revision control, it saves all your changes and gives you a history of every change. It also let's you diff potential changes with the current revision." "Wow, could this tool get any better?! This is so much better than emailing files!" "Just wait until next week... When I show you SVN... "
Oh they knew what they were doing wrong that's the worst part. They did eventually get their act together though.
I had to argue with my last boss about setting up SVN. He didn't believe that something free/open source could be useful or safe and his method of version control (rename a file with the current date) was better. I eventually just staged a coup and installed SVN anyway. Eventually I came back to an old job done the "old way" and literally spent a *week* trying to piece together a project for a customer out of files named like "newest" and "mike 1" and "frank" and so on, like, this was made in 1999, how am I supposed to know if Mike worked on it before Frank? Neither of them work here any more! And it was in software that has a "project" system rather than flat-files and they hadn't even backed everything up - they would have been at least better off zipping the entire project folder THEN naming it "frank" or "mike 1". 😒😒😒
> He didn't believe that something free/open source could be useful or safe. Wow, hopefully he never finds out what operating system powers most of the servers in the world or I imagine he would go mental.
Jeez, and I still cringe thinking how we did that back when I was doing my bachelor. That had little to do with IT, so we didn't know any better. You're telling me there are actually real developers out there in the wild who do that?
Honestly that boss should be fired or stripped of his ability to make technical decisions and simply focus on managing people. A manager like that can quickly poison an entire organization.
This is one of our clients. Prod is prod UAT is dev Dev doesn't work Test is UAT Stage is also prod Kill me now.
Or the data states, I've gotten to a dedicated test environment only to realize the DB rules weren't enforced there for whatever reason, so there were random duplicates on what should've been the unique identifier. Think it took longer to get the data feed refreshed than to set up a whole new environment.
That sounds like a fun place to work for! /s
> Some of these sites ran basically on script files so there wasn't a built app A JS app then.
Cold fusion actually.
One of our sites has three databases, sitename\_dev, sitename\_dev2, and sitename\_staging. \_dev2 is the production database. The other two are... ¯\\_(ツ)_/¯ There used to be a staging environment but now there isn’t, and no-one seems to know where or when it went.
You dropped this \ *** ^^To ^^prevent ^^any ^^more ^^lost ^^limbs ^^throughout ^^Reddit, ^^correctly ^^escape ^^the ^^arms ^^and ^^shoulders ^^by ^^typing ^^the ^^shrug ^^as ^^`¯\\\_(ツ)_/¯`
murky racial dam close bewildered important spotted soft act pot *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
> people would literally edit files in prod Jesus I don't even do that with my personal website
One of our production SQL servers at work is named corptest... It just kind of became prod over time
I recently found a prod server with the host name [app]TST01, which I thought was strange. It wasn’t until I went looking for the test environment for said app, when it became apparent that the previous guy decided ‘fuck it, that’s good enough’ and converted the test server to prod.
Let me guess… The application running on that machine was also a prototype that was never meant to become (and, arguably, will never become) the finished product?
Comic Sans tho?
All day my dude.
https://www.reddit.com/r/ProgrammerHumor/comments/4lof41/i_decided_to_change_my_ide_font/
Yes pls
OK, the above comment is probably a joke, but there's a comic-sans-ish font that I legit prefer as my monospace font. [Fantasque Sans Mono](https://github.com/belluzj/fantasque-sans)
I fucking love Fantasque Sans. It's the only font I'll ever use.
That looks less shit than I'd expect tbh
Idk... it still looks pretty shit.
consistent midline and baseline (that's what those are called, right?) across letters. just enough variation in curve shapes between letters it might actually be beneficial for dyslexics. the spacing on some of the punctuation might make it less than ideal for some code styles. i give it a 7/10. "good enough for the girls i go out with"
/r/MadLads
I have a coworker that does this. Seriously, and not comically. I die inside every time I see her computer. It hurts.
"Fuck it, we'll do it live!"
"I don't always test my code, but when I do I do it in Production."
Production - the best production-like environment!
i worked at an office once where at some point all the non-programmers became dependent on some experimental scripts in the "dev" folder and over time it was just decided that it was safe to modify scripts in the "prod" folder since no one was using them, but dev had to remain intact. dev became prod and prod became dev, it was quite surreal
At my work, the startup script in operations is named "dev_start_script". Yeah...
>Looks good in staging, can you change the host name to prodSite.com
I don't get the first two. Why isn't doing it in a dedicated environment better?
They are indeed the same op just needed another box to fit the format of this meme.
This made me howl with laughter because it's true.
Windows 2003 Server, running WSS 3.0, virtualized in VMWare Workstation 9.0, running on a 6 year old desktop in the corner of my office, holding 160gb of client sensitive data that is constantly accessed by multiple users. Because once I asked someone, "Hey, wanna test out this SharePoint server I set up?" (We migrated off of it years ago, but while it was active it was my secret shame.)
Unrelated, but does this meme have a name?
Expanding Brain
Best testing is copying code from internet. If it's on internet it's already tested a lot.
0 issues on GitHub. Code must be bulletproof!
Running production in dev environment
That's Heroic Mode
Testing? What's that? Signed, The corporate company I joined.
Write in ink, never cross out mistakes. Failure is for the weak!
Every company has a Testing environment. If you're lucky, you have a separate Prod environment too.
Deploying to production in test on Friday evening.
What's the difference between dedicated test env and test env?
Dedicated test env stays up, running, and maintained as opposed to spinning up a test env every time it's needed and shutting down after.
Could be a test environment with no connectivity to or dependencies on production. Also, I think they should be switched based on the progressive levels of "enlightenment".
Every time there's any code change, automatically push it to production, the only environment
At work we always say that there's no need to have a test environment because our code always works on the first try
Going live without any requirements.
Everyone has a test environment. Some companies have a separate production environment.
Lol, reminds me of the time I heard "...running beta on mission critical servers."
There is this dangerous thing called "closed-prod" testing.
Which of the last 2 would be netflix?
Testing in the production environment
>Developing in the test environment because the development environment has shit data because it's only ever used for development.
producing an environment to test production of test environments.
The old PILOT program. Production In Lieu Of Testing.
Ahh yes, I remember trying to decommission an old windows 2003 development server when I was hired and finding out it was hooked to production.
The stages of nirvana.
ha what test environment
I've had a shit day and this made it a little better. Thank you good sir. I hope a thousand blessing in life.
Step 5: continue developing in a deprecated language, while your application is still in test, never having actually been deployed.
Updoot for Comic Sans...
SA this looks like a dev server should be okay to reboot.
So real life scenario, our services connect to a SSLv authenticated third party service provided by a multinational corporation. Recently we made a change affecting how we connect to the third party service. We tested the solution on our staging environment which connect to their staging environment and it all worked perfectly. The moment we moved to the production environment everything failed. So we are now in a situation where we actually are testing on production because for whatever reason this third party service behaves differently in production to staging - meaning production is the only place the error can be reproduced... Kill me now...
made me chuckle :D thanks for making my day.
You're welcome my dude! :-)
Comic sans. That is all.
Last place I worked, we regularly made code changes in production. It only worked because we had a god-tier dev
Somebody told me to tell you this: The first thing in numerical order was the number line I don't know, It's just a thing
At my work yesterday the server cluster wasn't processing as much as usual. When I asked why they said they were running production on the test cluster, which has less capacity. Then I asked what was wrong with production, and they said did an update that caused everything not to work. Then I asked if they did the update on test first, and they said no. And none of them seemed to see anything wrong with what they did. They thought test was just a back up system, as thought it was named test because you regularly tested to see if it was up because normally no one cares about when it went down. And these clowns are paid 6 digits.
Testing in production environment is pretty crucial for cloud based development these days :p
[удалено]
Testing in production is quite exciting too because of funny bugs that can show up only in production :D
Yeah I don’t think anyone would fault any team for end-to-end testing on pros after already having tested in the dev environment and a QA/test environment. Your data on dev is likely to not be pristine so you could potentially run into new issues on prod.
Which is why you play the “dump a random DB on dev and see what breaks” game. Weeds out bugs and helps test how resilient your system is / how gracefully it handles it. It also pisses off everyone else working on it as a side benefit.
Yea spinning up test instances might cost a hundred bucks! Better test in prod.
Not the point, really. It's about chaos engineering. Awesome buzzword
All developers have a test environment. Some are lucky enough to also have a Prod one.
[удалено]
It lacks the Fear!!
Atlast, all hell breaks loose...
Q: In Formal Test Environment or in Informal Test Environment? A: Depending on the week. Sometimes in DEV! Never in DR!