1. Use a GUI and point-and-click your way through thousands of server installations, hoping you set the right things each time. Don't script it!
2. Save files and scripts all over the place, and if you want to make a change just edit it somewhere and have mismatched versions all over the place. Don't use version control systems.
3. Think of a server as a pet. Keep it alive, keep it running, keep patching it. If something goes wrong spend hours and hours to figure it out. Don't treat all your servers like cattle, spinning up and tearing down and rebuilding via automation as needed.
4. Leave resources running 24/7 that you don't need. Don't worry about consuming cloud costs.
5. Don't work with your colleagues on how you can continually, incrementally be doing things better and smarter with automation and documentation. Do whatever you want, whenever you want, no matter if you remember it later.
Is that what you were after?
Yes there are day0 deployments but these early deployments often do not catch issues at scale
This might look expensive to start with, but will be super productive and economical as the teams cruise along. This is a huge cultural shift and would take good time to settle down and be productive.
This usually goes hand-in-hand with the sacking of testing, quality assurance, change management and infrastructure specialists.
But the worst thing I have seen organisations do is outsourcing the Dev and Ops part. Some organisations outsource the Dev and keeps the Ops. Or, conversely, outsource the Ops to a cloud service provider and keep the Dev. OR outsource both to different providers.
I've yet to see that strategy deliver successful outcomes to the consumers of these outsourced relationship; although the financial controllers are generally happy with the cost savings such arrangements achieve.
In summary: DevOps and outsourcing (seldom) go hand-in-hand - certainly not as a first step in transitioning from a legacy environment to a more modern one.
Content you might like
Limited environment/Infrastructure resources32%
Inability to quickly identify the root cause of CI/CD pipeline failures45%
Lack of standardized CI/CD pipeline templates across the organization54%
Integrating security tools - inefficient security implementation leading to false positives38%
Poor communication across business and product teams/coordination challenges26%
Cost/resource management26%
Implementation of CI/CD into on-going projects and workflows22%
Internal resistance: training issues, culture, etc.14%
Inefficient implementation of CI/CD due to lack of expertise, poor training, etc.19%
Poorly written unit and acceptance testing9%
We are not doing regression testing10%
25% manual, 75% automated50%
50% manual, 50% automated27%
100% manual, 0% automated8%
Don't know2%