It does not exist yet, I've filed BM-3326 to add it in v6.1.2

While we don't have a "first class" Quality Center integration, we have a number of customers who have done this. Unfortunately, HPQC automation is not easy, especially to generalize into a plug-in, which is why we don't have built-in support for it. But there are a few general things to keep in mind as you design a process around this, and of course please don't hesitate to reach out for more help :) Of course, BuildMaster can run "anything" with a commandline-interface using the Exec operation. You can create a Powershell Script to surround this, or a OtterScript module to give you a consistent set of arguments. Unfortunately, QC doesn't have a commandline, but it does have a COM-based OTA API that can be used to build a commandline tool that BuildMaster then calls. You could also build an extension using the Inedo SDK that calls this API, but in this case, building your own CLI is typically easier, because you can independently test it, and it offers some isolation against problems with the COM-based API. It does appear that QC has a REST API, but it is a "technical preview" and probably isn't feature complete. You may be able to use it, which would be a lot easier, since you can just use PowerShell or built-in operations to make simple HTTP calls. Hope this helps a little bit!

Sorry about that - we accidentally broke SDK compatibility and will have to release a newer version of BuildMaster (v4.7.5) that will have a shim for that method. As a workaround for v4.7.4, you can call: StoredProcs.Applications_GetApplicationsVisibleToUser("Admin", "", 1) to get apps visible to the Admin user of the built-in directory provider (substitute a domain user name and use directory ID 2 if you're using LDAP). This of course assumes the default setup where "Admin" has privileges to view all applications.

A patch is available below; run the contained SQL scripts against the BuildMaster database in any order to resolve this. Note that this fix only applies to v4.6.3-4, and will be included in v4.6.5: http://44.inedo.com/buildmaster/CloneAppPatch-v4.6.4.zip

Hey Alana, That option sounds fine to me. I certainly think it would cut down the time to spawn up new Applications for us.

Using a \ character is correct for escaping in JSON; that should work. We will try to reproduce this, but in the meantime are you able to use single quotes instead in the XML? Assembly='BuildMasterExtensions' should also parse as valid XML if I'm not mistaken.

You could try calling the stored procedure directly via the SQL API: DECLARE @B VARBINARY(MAX) SET @B = CAST('yourname' AS VARBINARY) SET CONTEXT_INFO @B EXEC Applications_PurgeApplicationData @Application_Id or view it in SSMS to see the actual SQL.

In general, we recommend going with a "business context friendly" name for your application. There are several reasons for this, but it mostly goes back to the fact that it's a lot easier to share/consume friendly names. There are times, however, when it makes sense to match name/code/scm/etc., and this is usually when there's a "conventions" approach. For example, our extensions (see BuildMaster Implementation Specifics) use the application name to determine a lot. But this usually only makes sense when you have a lot of "cookie cutter" componentized applications (such as in our case). So for your example, I would say name it "Awesome", and then have multiple deployables within that application. I wouldn't use the word "solution" unless it's actually part of the business name. For us, the application name is "BuildMaster" not "BuildMaster Solution"... even though our codebase has a "BuidMasterSolution" folder and a "BuildMasterUbserSolution.sln" file.

See Q&A 947. This will be fixed in 3.7.1; but a patch is available. Just email support - at- inedo - dot - com, and we'll send it over. In the mean time, I've emailed you the patch.

Your best bet would probably be to use the Clone method via the API: http://inedo.com/support/tutorials/cloning-an-application-with-the-sql-api

I would just move it to an application group called "Inactive".

This will be fixed in 3.7.1; but a patch is available for those on 3.7.0. Just email support - at- inedo - dot - com, and we'll send it over.

There is no "application export" functionality since the goal is to have 1 instance of BuildMaster that controls the release and deployments from SCM through Production. The only things you can do at this point are re-create the steps manually, or play with the SDK to write a custom recipe that both exports an application into some format, and also can import it. Unfortunately we don't have any recipe creation tutorials at this point, but we could send you some code as an example you'd like (they're pretty simple if you already know C#). The best thing you can do would be to solve the infrastructure problems around the Production environment and allow BuildMaster access to an agent installed on the server(s) of that environment. This way you'd have a single instance of BuildMaster and would only have to manage a single deployment plan per application.

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