5 ms·

I particularly love the suggestion to just document what you're doing as the first step to proper automation. It's not that much work or cognitive effort. Somet

I particularly love the suggestion to just document what you're doing as the first step to proper automation. It's not that much work or cognitive effort. Sometimes a decent description of your procedure is all you will need and it tends to prove very valuable later. It can be also gradually improved. I was doing it often already, and this will remind me to persist.

noir_lord 7y ago
I use checklists for that. The second time I do something o make a checklist, at a certain point I decide I need to automate it and I have all the steps mapped out to start from. It works well on practice because a checklist is quite mutable, if something goes awry it gets added as a step the next time until I've covered the edge cases. To make them I use vscode, markdown/journal plugin and mdpdf to print them to pdf, so they can be source controlled easily as well.
mikepurvis 7y ago
This is very true. I stand up a server every now and then and just define the setup as a single-file Ansible playbook— pretty much no matter what, it'll be some combination of packages to install, users to create, config files to modify, etc. Why write it down when I can just define it as code and check it in somewhere? But then the IT department comes along and hates it; they make a wiki page for each server with a list of instructions for what was done. Their approach is more flexible, as not every tool/step can be easily or robustly automated, and if you can just screenshot the config webpage and paste it into your wiki, that might be just as good as (and a lot faster than) spending an hour trying to bypass that step. Plus, their approach assumes aggressive use of VM-level tools. Where I'm like "oh, I need N build slaves? Let me add them to my inventory file and re-run", whereas they're like "N build slaves? Sure, I'll set up the first one manually and the clone the machine for the others." I know there are real actual advantages to version controlled configuration, but there is something pragmatic about just doing the thing and keeping human-readable notes as you do it.

noir_lord 7y ago

I use checklists for that. The second time I do something o make a checklist, at a certain point I decide I need to automate it and I have all the steps mapped out to start from. It works well on practice because a checklist is quite mutable, if something goes awry it gets added as a step the next time until I've covered the edge cases. To make them I use vscode, markdown/journal plugin and mdpdf to print them to pdf, so they can be source controlled easily as well.

mikepurvis 7y ago

This is very true. I stand up a server every now and then and just define the setup as a single-file Ansible playbook— pretty much no matter what, it'll be some combination of packages to install, users to create, config files to modify, etc. Why write it down when I can just define it as code and check it in somewhere? But then the IT department comes along and hates it; they make a wiki page for each server with a list of instructions for what was done. Their approach is more flexible, as not every tool/step can be easily or robustly automated, and if you can just screenshot the config webpage and paste it into your wiki, that might be just as good as (and a lot faster than) spending an hour trying to bypass that step. Plus, their approach assumes aggressive use of VM-level tools. Where I'm like "oh, I need N build slaves? Let me add them to my inventory file and re-run", whereas they're like "N build slaves? Sure, I'll set up the first one manually and the clone the machine for the others." I know there are real actual advantages to version controlled configuration, but there is something pragmatic about just doing the thing and keeping human-readable notes as you do it.