Viable solution for multiple release Application

In the older Buildmaster which I've replaced (and do not want to go back to) my Legacy Action was to create the Artifacts for each release level I wanted for later deployment in my plans.

In the new buildmaster this appears a bit more difficult or, at least, the option to do so seems to be a bit -- unfriendly. It seems I now have to create a new Pipeline or add a new Import step to my already existing Pipeline. The second step sounds the best, but I have concerns now (after thinking this through) that there is a very real possibility of code changes between builds, causing my release build to contain untested code.

I was speaking to Buildmaster support and asking a question about labeling as this seemed like an acceptable solution, but I cannot determine how best to implement this using BuildMaster as the control. Is there any method to "get label version" from TFS/VSO for a build import?

MSBuild supports GetVersion to get a specific version for a build, and from a devops standpoint this is almost a necessity. It is possible to customize, but seems like it would fit core Buildmaster much better -- variable for build label, correctly pulls proper labelled code and builds/rebuilds as expected.

In the end, I want BuildMaster to be the center of our deployment environment, so if this is not feasible: What is the best way to ensure that the code I deploy for another release is the same source-set I deployed to the previous environment?

Product: BuildMaster
Version: 5.0.6

We will be moving away from the "Build Importer" concept in v5, and instead favoring simply using a plan to import a build. This will remove a lot of limitations that the build importers have.

In the older Buildmaster which I've replaced (and do not want to go back to) my Legacy Action was to create the Artifacts for each release level I wanted for later deployment in my plans.

This would be the v5-approach as well, but we didn't get the corresponding v4 Actions converted into v5 Operations yet. We are doing that now, and should have new versions of the corresponding extensions shipped in a few days.

The work-around for v5-plans is to use the Execute-LegacyAction operation, until we can get the operations built. But the strategy is the same... import the artifacts during the first stage in your pipeline, and attach them as artifacts to your release package.

Hello Alana,

Thanks for the answer, glad to see I was 'doing it right'! I will wait for the ImportVsoArtifactAction and QueueVsoBuildAction to be completed.

Kind Regards,
Kevin

Hello Alana,

I just wanted to circle around and check on the extensions update for these items. While using the Legacy Action operation is a working method, it does "feel like" the wrong way to use BuildMaster and I am reticent to keep deploying our new applications into the old method. I also really don't want to migrate all my applications to this method and have to swing through and migrate them again, but they can sit where they are for now.

Kind Regards,
Kevin

Well be releasing BuildMaster 5.1 in just a bit (later today), which will have these operations.