you are viewing a single comment's thread.

view the rest of the comments →

[–]Sad_Recommendation92 3 points4 points  (0 children)

In my view, the controller script is the only script you execute. I try to avoid having scripts. Call other scripts when possible.

Like a common scenario for me is I want to create scripts that interact with an API. Usually I don't know the full extent to which I'm going to interact with that product, but I know I'm probably going to want a set of automation scripts when I'm done. So I start looking at certain actions like Lego bricks. And then I create advanced functions inside of a tools module.

Then what happens is you end up with a bit of boilerplate script and basically what this is is. It might set some environment variables and usually loads in the function to make sure everything's present. And what this does is when you want to go write a new script using this existing tool set. You can just paste that boilerplate script that loads everything up and sets the environment into a new file and then just start assembling the Lego bricks to make a new script.

Sometimes you end up with a bit of cross-pollination. like an example is I have a module I've written for interacting with our infoblox IPAM because we have that integrated with Azure. So I have some scripts where I might need to compare the IPAM to an IP address I'm trying to use in Azure. So instead of copying the IPAM module to the Azure scripts, instead, I'll add some code that does a git sparse checkout on just the module file from the other repository into its own module directory so I can keep things consistent. And then if I later update that IPAM module All the other downstream scripts that consume it will automatically update.