For me at least, this is the whole point of DevOps. I cannot prove I have control over the production environment if anyone can make changes to the behavior of the system without some audit trail and a plan to roll back any changes if necessary.
At an EpiUsers’ Insights session, and to many boo’s in the crowd, @Bart_Elia said his goal was that developers and even admins could not change production (servers or code) directly. Full stop. There should be a test system to stage and check the changes, and then a build service or IaaS service that did the actual building and/or changing of the production system.
Why?
- This allows IT people to take vacations. Each process is documented and logged. This goes to @timshuwy irreplaceability maxim. Being the only person to know how to do this makes me a liability to the company, not an asset. Here at PTI we had a deeply embedded consultant pass away, and we still don’t know how much of that code works since we lost the source code too.
- In the unfortunate case that a system needs to be built from scratch (fire in the computer room, natural disaster, cyber incident, etc.), all of the instructions to rebuild the system are there and can be automated for a quicker recovery.
- Test Systems can be built quickly, and if we’re really good, seeded with our own demo data instead of using production data for better information security.
- Upgrades are easier if there is an automated way to compare before and after versions of objects (RDDs, Kinetic UI, SSRS reports, …). This includes comparing the current base version to next base version and then changes from the next base version with our changes.
In my personal opinion, worse. This is why I call these tools Pet Builders. They are great development tools, don’t get me wrong. But they encourage building systems that are difficult to upgrade and recover without some framework to do so. I don’t think it’s fair to blame customers for not upgrading when the tooling promotes development chaos.
Working in a structured and controlled way removes the entire need for this and all of the other threads about documenting changes because the documentation is built directly into the process. I have exceeded my DevOps ranting quota, and I yield the balance of my time to the other fine ladies and gentlemen of this forum.