Approach for distributing/consuming reusable tasks

[JamesDawson]

Hi,

Thank you for all your efforts with IB it’s such a solid & flexible tool, we use it to orchestrate a variety of DevOps processes. As such we have built up a collection of tasks that implement our opinionated build & deployment processes, which we take from project to project. We use an approach based on Example 2 in your article about sharing tasks.

As that collection has grown the repo with these tasks, that span different domains & technologies, has become increasingly unwieldy. Also, not all the functionality is relevant to every project, but it’s been difficult to pick and choose as they are bundled into a single module.

I’ve recently been experimenting with a type of extensibility/distribution model (for our opinionated processes, rather than IB), where:

• sets of related tasks can be packaged into their own PS modules similar as above (notionally called extensions)
• consuming projects declare the extensions they require
• a core module that resolves, installs & loads the required extensions
• IB is then called as normal (we tend to use the bootstrap approach)

I’d be interested to hear any thoughts you might have on the concept:

• If you ever pondered this type of thing before?
  • If so, was it as part of IB or something separate?
  • If not, would you have any issues with us open sourcing it as something separate (it wouldn’t have IB in the name, but would obviously reference it)
• Whether you think it’s a crazy idea and we’ve clearly lost our minds/missed something that already does this! :-)

Thanks again!

[nightroman]

Hi @JamesDawson , thank you for the very interesting topic. I am interested in all ways of sharing and distributing tasks. There is not a single solution and probably should not or cannot be.

I have lots of IB scripts, quickly counted some 500+ (including test scripts with tasks). Interestingly, I do not have mush shared stuff between them. But when I have I tend to share build task oriented commands, not tasks themselves. Then build scripts import these commands (modules or scripts) and tasks call functions with appropriate parameters. This adds some boilerplate to tasks, yes, some become literally the same in different scripts. But such tasks are very simple, they just call external commands. Yet at any time I have the ability to alter call parameters or add extra code to tasks. Bonus, task oriented commands may be used without IB as such.

I have no issues with you open sourcing your approach to shared / distributed tasks as something separate, and the project name is totally up to you. I am happy when IB users do this. I believe I've seen such projects on GitHub, I'll bring them to this discussion if they are found again.

[nightroman]

@JamesDawson Some new development, likely related but not necessarily applicable in your case.
Build script inheritance extends dot-sourcing