[nameless912]

> Debugging directly on the production system? Yeah, nobody does that.

Uh, what bubble are you living in? Almost everyone does that to some extent. We can all pretend we're code ninjas with super clean deployment pipelines and strict policies, but all of us get lazy occasionally.

[thinkmassive]

Not to mention that, in any successful project, there are going to be systems that need to be looked at by someone else. It's great for the original developer(s) that they can use their IDE to access files directly in containers, but if I'm called to investigate a running system then I'm going to end up in a shell on those hosts.

The only place I can see this never happening is in large enterprises that have huge departments with slow enough turnover that "the accepted workflow" is easily passed on to new hires. Referring to everyone else as "mom & pop shops" makes it sound like the speaker is living in a Silicon Valley enterprise bubble.

I find it amusing to see that term used as an insult on a site largely populated by startups.

[rantanplan]

Sounds pretty self-serving to say that I "referred to everyone else", just because you want to justify sloppy processes. I only referred to those who do that, and I'm sorry if I'm bursting anyone's bubble here, but nope; not everyone does that!

Also a startup doesn't necessarily have requirements for serious ops, but it may, some day. Well if they want to be an enterprise at least. You do know what the goal of a startup is, don't you?

And btw, no I don't live or work for company in SV. Europe mostly, with a dash of Dallas, Texas in the mix.

In any case, I was hoping for engineering arguments, not personal attacks. :(

[fattymagoo]

dont no

[rantanplan]

"Almost everyone does that".

No they don't. I am not living in a bubble. You're describing a mom and pop shop.

And by the way you don't have to be a code ninja or have a super devops team for that.

You can have your code locally, point your DB config to a staging server with a copy(you do backups daily, don't you?) of production and boom!

Seriously now... elementary stuff. If you're still changing code directly on live systems you have a long way to go.

[nameless912]

And you're describing a pipe dream that doesn't happen in real engineering orgs. I think I can speak for most people here when I say that the best of DevOps intentions only last until your first fire. You can design for best practice, but odds are something will happen that requires you to jump onto a moving train and figure out what the hell is going on. That doesn't mean that DevOps is pointless, it just means that a dose of realism is required to understand how to do real engineering. Sometimes you just won't be able to do things the "right" way because you only have time to do them the "wrong" but still working way before your customer gets pissed. The real world has very different requirements than a management textbook.

[rantanplan]

Well I don't know what your friends, social or professional circle is, but it does happen.

What I describe is not out of a management textbook. This is really really elementary stuff if you want to sustain any serious operation.

Let me explain: so you're saying a customer is on fire. Let's say that a query generated by that customer for some reason it creates a spike in your DB. Let's say that it almost DOSes your system. You know it doesn't happen locally, with your dummy/fixture data and it doesn't happen with other users/customers. So some particular configuration of state(your DB) is creating this problem. What are you gonna do my friend? Retry the query on production while you have a debugger on the webapp process? Please... be serious.

Remember, it's only once you have to setup this kind of infrastructure(and you can scale it up or down depending on your resources). And then you can do business like a normal person. What you describe is like throwing my sanity out of the window every time there's a severe(or not) support issue ticket. It doesn't scale!