3

I have a Visual Studio solution with one SSRS project, two SSIS projects, one SSAS project and one SQL Server project. I'm using TFS2013 Update 4.

I'd like to deploy this solution using TFS Release Management in two environments. First environment should be "populated" after the developer's check-in and in the second environment the projects should be deployed only in the next night (during the day the environment is used by the testers and a new deployment can affect their data).

It's possible to achieve this with TFS Release Manager 2013.4?

Update 1:

A single gated check-in build is taking too much time and that's why in this moment I have gated check-in builds separate for each project in order to keep the developer's waiting time to minimum.

Update 2:

The current setup is with five gated check-in builds that are building and deploying each project to the first environment and one nightly build that is building and deploying to the second environment the entire solution.

ds19
  • 3,176
  • 15
  • 33
  • Are you hoping to have this completely automated or can you accept a daily manual intervention for deployment to the second environment? – Graham Smith May 27 '15 at 16:03
  • A manual intervention is accepted because it can be automated through the API. – ds19 May 27 '15 at 16:12
  • Are you planning to start RM through the API since an RM template can only point to one build definition? Actually, can you say a bit more about what's happening in the first environment since your setup feels like it's going to end up being very complicated when it may turn out that the complications are unnecessary. – Graham Smith May 27 '15 at 20:20
  • Or you can have an additional "collector" build, that you automatically queue from the others whose purpose is to collect artifacts and be the reference for RM – Giulio Vian May 28 '15 at 05:57
  • @GiulioVian it seems to be most elegant solution; if you add it as an answer I can mark it. – ds19 May 28 '15 at 08:33

1 Answers1

0

Add an additional "collector" build, that you automatically queue from the others whose purpose is to collect artifacts and be the reference for Release Manager.

In other words, say you have five CI builds, one for each project named CI1 to CI5. In each CI post-test script you run a similar command

TFSBuild start /collection:%TF_BUILD_COLLECTIONURI% /buildDefinition:Collector /queue /msBuildArguments:CIDrop=%TF_BUILD_DROPLOCATION%

to queue the Collector build. This latter collects the artifacts from the parent build and the last know good artifacts of the remaining CI builds and copies them to its drop location.

Now you can use Release Manager as usual on this Collector build.

Giulio Vian
  • 8,248
  • 2
  • 33
  • 41