Using Imported Deployables

Let's say I have two BuildMaster applications. One is the primary application, and one is enterprise service bus code (ESB). The primary application and the ESB are versioned and deployed independently, but sometimes the primary application requires an ESB deployment. This is where I want to use imported deployables. My thought is that on a given release of the primary application, I can choose whether or not to include that ESB deployable.

I imported the ESB deployable into the primary application. Now what? How do I make use of this imported deployable? Do I add a step to the primary application's deployment plan to deploy the ESB artifact? Should I create linked action groups in the primary application's deployment plan that are linked to the ones in the ESB deployment plan?

Am I on the right track?

Product: BuildMaster
Version: 4.1.5

Hi Glenn,

Good question; it sounds like you're on target.

With imported deployables, you'll want to create an action group associated with the imported deployable, and then deploy the artifact from the imported deployable.

You can see some use of this in the implementation Specifics, especially the one for the BuildMaster installer.

hope that helps!

So when the primary application goes to deploy the imported ESB deployable's artifact, does it matter where the ESB's release is in the environment pipeline? For example, if I'm going to promote the primary application to Production, but the ESB build is still in a Dev environment, will the primary application deploy the ESB artifact to Prod anyway? If so, what's a good way to prevent this?

There are no restrictions on which environment the associated artifact is in: for example, if both ESB and MainApp have a four-environment workflow (Int, Test, Stag, Prod), then you will be able to promote MainApp to Stage while ESB is still in Test. You could, however, write a promotion requirement to prevent this.

There are, however, restrictions on promoting to a final environment when a dependent release is not "deployed". For example, you could not deploy MainApp to Production if ESB was not deployed to Production. This can be overridden with a force.

The reason we don't have the "environment by environment" restriction is because library applications tend to follow a different workflow (Testing > Release) than regular applications (Int > Test > Stage > Prod), and matching because too difficult to generalize.

Thanks, it's good to know that we couldn't deploy MainApp to Production before ESB is deployed to Production.

I also could see using change controls to enforce this as well. Thanks for the suggestion.

If we wanted to be really, really certain that ESB is deployed to whatever environment we are promoting MainApp to, would it then make sense to create a liked action group in MainApp tied to the ESB deployment steps? That way, an ESB deployment would occur as part of the MainApp deployment. Is that the best way to do that? If so, does doing it that way also update the ESB application release progress? For example, if we are deploying MainApp 1.2 to QA, and ESB 1.1 is in QA, would the MainApp 1.2 QA promotion update the ESB application to show that ESB 1.2 is now in QA? That's what I would expect, but want to confirm...

The linked action groups are more about "code reuse" than anything else. But you may want to check out the Promote Build and Create Build actions; those come in handy when dealing with dependencies like this.

Usually, you'll see a promotion of ESB trigger the MainApp.