Doctor Who 2 wrote:
Steve, you've hit upon the biggest issue I contend with at work, concerning trying to get DevOps going; that's changing both people and processes. I'm a developer who I called an Accidental DevOps Engineer because I was given the job of TFS Administrator when the former TFS Admin left. Then later when we sorta tried to get Azure DevOps going I was made the Azure DevOps Administrator. However, like so many other places, the prevailing thought is that you rub a little DevOps (i.e.: whatever DevOps tool you use) on, then presto-chango, you're a DevOps company. But at the end of the day, people don't want to change, and they don't want to change processes. I know that several other places must deal with a similar misconception of what DevOps means to a company and culture.
Pretty much this. A lot of people don't want to change. It's a major disruptor to a lot of organizations. For example, the idea you can now spin up a SQL database with a simple script, have it mirrored across all environments, and deployable by a developer without an DBA is a huge one. Think about that. You no longer need a DBA to deploy a new database instance for your feature branch. You can now have a database PER feature branch if you really wanted to these days. Isolated databases only for a developer to work on where the password, users, etc are changed automatically between staging and production. Big concepts that most IT teams don't want to adopt because it takes a lot of power out their hands.
DevOps is more about a methodology than people. If you cannot get the business to adopt the process/methodologies. You are screwed.