When modernizing your technology/work framework you don’t need to introduce:
- A full Kubernetes setup
- Helm charts
- Complete CI/CD pipelines (and let alone templates)
- Full fledged scrum cerimonies
- Production level security requirements to deploy
all at the same time. In fact, it may even be damaging long term or counter productive.
The cognitive load and the practical new blockers that will inevitably pop up when trying out / implement new tools (especially the ones changing paradigms, e.g. K8s instead of VMs/puppet scripts) will only add a bigger upfront cost in catching up on multiple fronts.
Don’t push all of these production-level requirements to developers. Let them have QA-environments where they can iterate, fail and experiment fast without imposing many rules, especially when their purpose is to introduce new tool X, not to make it production grade.
“Rotate in” one or two things maximum at the time, and don’t push to immediately reach “production level” (whatever that may be).
E.g. instead of starting from the “ideal” CI/CD pipeline for an old Python 2 script and filling in all the steps so you have whatever running as soon as possible on your target cloud (e.g. Azure DevOps), do one step at the time:
- Migrate to a new LTS (e.g. Python 2 -> 3)
- Package the software correctly (e.g. evaluate/de-risk the usage of Poetry/setuptools)
- Check dependencies and reproducibility of setting up the developer environment procedure
- Verify that you have proper unit tests, make sure they run locally
- Prepare a container image, if that may help during development to quickly bring up the desired environment