Every ops team has some manual procedures that they haven’t gotten around to automating yet. Toil can never be totally eliminated. Very often, the biggest toil center for a team at a growing …
I like the idea, but I wouldn’t really know how to put it into practice. It works quite well, if you’re using Python to automate, but if you’re using more dedicated tooling for CI/CD automation (à la Ansible, Puppet etc.) then those tend to not really have a way to pause execution until a user input happens. It’s kind of anti-thetical to their end goal…
I guess, you could have a Python or Bash script, where each function just calls an Ansible task and once you’ve automated a chunk, you replace that with an Ansible playbook. But yeah, really not sure, if that’s terribly sexy in practice.
Highly recommend having some scripting/interpreted language in your stack – in fact you likely already do (consider how shell scripting makes up a significant part of Dockerfiles)
It’s an incredibly useful intermediate between freeform-but-non-executable text/docs/wikis and “industrial-grade”-but-inflexible tooling
In other words, a great fit for capturing this partial/incomplete/tribal knowledge space the post is talking about. I personally even go a bit further and actively advocate for converting “onboarding/operational docs” from wikis into scripts that print out the equivalent text that can be committed and incrementally automated.
I like the idea, but I wouldn’t really know how to put it into practice. It works quite well, if you’re using Python to automate, but if you’re using more dedicated tooling for CI/CD automation (à la Ansible, Puppet etc.) then those tend to not really have a way to pause execution until a user input happens. It’s kind of anti-thetical to their end goal…
I guess, you could have a Python or Bash script, where each function just calls an Ansible task and once you’ve automated a chunk, you replace that with an Ansible playbook. But yeah, really not sure, if that’s terribly sexy in practice.
Highly recommend having some scripting/interpreted language in your stack – in fact you likely already do (consider how shell scripting makes up a significant part of Dockerfiles)
It’s an incredibly useful intermediate between freeform-but-non-executable text/docs/wikis and “industrial-grade”-but-inflexible tooling
In other words, a great fit for capturing this partial/incomplete/tribal knowledge space the post is talking about. I personally even go a bit further and actively advocate for converting “onboarding/operational docs” from wikis into scripts that print out the equivalent text that can be committed and incrementally automated.