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 …
  • talkingpumpkin@lemmy.world
    22·
    2 days ago

    TLDR:

    What the author baptizes “do-nothing scripts” are interactive scripts that print out the steps of some procedure one by one and wait for you to confirm each step (eg. “1. do this. press enter when done” “2. do something else. press enter when done” and so forth).

    PS:

    @OP (if you are the author)

    I HATE those sites where popups come up when you are halfway reading something.

    What’s the idea behind it, besides annoying your users as much as possible?

  • Ephera@lemmy.mlEnglish
    3·
    2 days ago

    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.

    • Kache@lemm.ee
      2·
      18 hours ago

      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.

  • _____@lemm.eeEnglish
    8·
    2 days ago

    I have nothing to add except: man’s really wrote like 7 classes to just have 1 function each

      • _____@lemm.eeEnglish
        3·
        2 days ago

        Honestly, if they want to go full enterprise at least use the javabeanfactoryfactoryfactory pattern

    • Ephera@lemmy.mlEnglish
      1·
      2 days ago

      Yeah, I’m really wondering why they thought this was a good idea. My best guess is that they want to keep everything within one file, since it makes the script easier to deal with. But when automation actually starts being implemented, they want the functions for each task to be grouped (and I believe, Python doesn’t support inline modules), so they abuse classes for that…?
      Well, and I guess, it allows them to have pseudo-constants within each task, which don’t need to be explicitly passed around between functions.

      But yeah, really not a fan of needing this much boilerplate to start out with. In my opinion, the activation energy required to use this pattern instead of slapping down documentation needs to be as minimal as possible, otherwise folks will slap down documentation instead.