[johngalt]

DevOps is the intersection of three things.

1. Developers learning that running code is not the same thing as reliable code. Certain things must be put in at design time to allow for operations.

2. Operations people supporting development by formalizing/streamlining the deployment process to have changes occur faster, safer, and more often.

3. Aligning goals and attitudes in such a way that prevents conflict between teams. Development doesn't get to shift the costs of outage prone unmaintainable code onto an ops team. Or that ops doesn't roadblock/veto all changes.

In the bad old days, it was common for developers to act with little care for operational outcomes. The responsibility was far removed, and bugfixes didn't win many accolades. Managers want wish fulfillment and pushed developers to toss new features into the mix as fast as possible, resulting in tremendous pressure against ops teams to deploy despite increasingly crufty and debt laden code bases causing unpredictable problems. Ergo, ops teams who blocked all changes for trivial issues because they were judged only based on outages, not feature delivery.

[ozim]

Yes, devops is not one person, but team is devops. It comes from standards, that developers should not have access to production data, so you need ops. But on the other hand you don't want to have dev and ops team people who throw shit over the fence.

So basically it comes to having devs, test, ops, sec, persons in one team with common goal of delivering featuers.

Because most friction was on boarders like dev | test | ops | security, all those people being on role specific teams would do what is important for their team. So test people would blame devs, sec people would blame ops, test or devs. When you are in one team that has common goal of delivering feature X and you are measured by delivering feature X, everyone is willing to take pragmatic approach instead of "code has to be perfect", "tests have to be perfect", "security has to be perfect".

I read somewhere "magic happens if you seat testers and developers in the same room", I belive it was "Project Phoenix" book. But I despise from the start having those devs vs test people or test people beeing happy about finding bugs. They should be sad because what matters is delivering feature, so they should be happy when they don't find anything. That said, thay should do all they can to find bugs, because we have common goal: "working software".