View Question

Good news! We have migrated all the Q&A on this site to https://forums.inedo.com, and are currently monitoring questions there!

Here are some important links:

All posts here are permanently locked (and will be redirected soon), and if you have any issues with the new site, please submit a support ticket, use the contact form, or visit our Slack Workspace.

One of our installations contains many pieces - website, web services, background apps, windows services, queuing mechanisms, desktop GUI apps, etc. Written in a number of different languages, and built as separate projects.

There are, of course, dependencies among them. Most work against a common database, and have a dependency on the table schema. The older VB desktop GUI apps (which we've not yet been able to eliminate) depend upon a COM object, written in C++.

I've been reading through your whitepapers, and everything seems simple and clear, there. Mainly because the examples are simple and clear.

How do you deal with more complex situations?

Does a build wrap a single project? Or can it wrap multiples? How does Buildmaster deal with dependencies between projects?

Does a release map to a single projects? Or can it contain multiples?

Would a complex environment of the sort I've described be organized as a single release? Or would the various parts be handled as separate releases?

Is there any mechanism for meta-releases? For a top-level release that contains multiple lower-level releases?

Hi Jeff,

Great questions.

We try to deal with complex situations as simple as possible, but complex things can get complex. So, of course, "it depends".

We're starting to document some of these in our specifics section ( http://inedo.com/specifics ) -- it's a work in progress, but we hope it gives some idea.

The first step is to "translate" your organizational specific terminology to BuildMaster's terminology. We model software development as a whole, so we can implement really any structure process... it's just about figuring out what should be a deployable, what should be an application, etc. The "Release Management Done Right" whitepaper discusses the terminology we use.

With only the information you provided, it's difficult to give specific advice, but from what it sounds like, the question is between Applications and Deployables. There's a KB article on the topic - http://inedo.com/support/kb/1032/the-difference-between-deployables-and-applications - that discusses differences.

Dependencies are defined at the deployable level (AppX depends on EntFramework) and used at the release level (AppX 3.2 depends on EntFramework 2.0). This enables all sorts of complex patterns we've seen implemented.

Feel free to contact us ( http://inedo.com/contact ), and we can discuss this in more detail and possibly help build a proof of concept.

Best,

Alex