One overarching web app with many self-contained applications under it

We have one web application that actually consists of several AppRoots in IIS that each have their own application with its own product life-cycle. Is there a concrete example of the recommended approach to handling this in BuildMaster. I gather it may have something to do with deployables but I'm really struggling with what the heck a deployable actually is / does.

Product: BuildMaster
Version: 5.6.9

Based on "each having it's own lifecycle", they should be separate applications. You can share pipelines, plans across applications.

Deployables are less useful these days, especially with variables everywhere and the new execution engine. So I wouldn't recommend using them. We're not considering them a legacy feature at this time, but they will not be brought to Hedgehog.

An overarching application could come in handy if you need to deploy all of them at once; you can use variable functions like APplications IN Group to loop over all the "Child applciations" and then deploy those using operations. Note that, in Hedgehog, you will have nested applications (likely: "Projects") that will make it a little easier to model. But still totally doable now.

Thanks for your response Alana.

You mention sharing pipelines and plans across applications. Were you referring to the global pipelines and plans or is there a way to limit the sharing within an application group?

Is there any concrete example you could point me to that illustrates a parent/child application setup? I get the concept of looping over applications in a group using the variable functions available but I'm still really unclear about how to structure and orchestrate the process from there. Specifically, what's the best way to divide responsibility between the 'parent' and 'child' applications. Do I have to build the create releases for the child apps manually first and then have the parent look for those? I'd like to have the parent orchestrate the whole thing to make the process easy for the operator (i.e. other team members) but I'm not sure I'm thinking of all of this correctly. For instance, I may only want to deploy 2 of the 5 child applications. Deployment currently includes kicking of a Jenkins build. Assuming the whole process is orchestrated by the parent application, how do I communicate the parameters I want passed to that build from the parent to the child application.

Unfortunately we don't have a good example case for this, because each scenario is kind of complicated.

what's the best way to divide responsibility between the 'parent' and 'child' applications. Do I have to build the create releases for the child apps manually first and then have the parent look for those?

You could certainly use the Create-release operation to create releases, but that may not be what you want. One factor to consider is, how different are each of these releases? Do you have a lto of variables you want to set? That will impact the ease of the interface you create.

I'd like to have the parent orchestrate the whole thing to make the process easy for the operator (i.e. other team members) but I'm not sure I'm thinking of all of this correctly. For instance, I may only want to deploy 2 of the 5 child applications.

If you only have 5 applications, then it's a lot different than 50 applications.

One thing you could do, is five different variables (DeployApp1, DeployApp2, etc). You could also do a list variable that has all five of those in there.

The more you generalize, the more complicated it gets... and with only five, maybe yo dont need to generalize that much.

Just a thought, but one idea I have... You could write up your proposed-setup (and why you set it up this way), and we could review it. This could be something we do as a blog-post, so we could share it with others. Writing it up will help give you clarity on it as well.