Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm thinking of using TFS Build workflows for complex deployments. We have some that may need to deploy:

  1. Web applications and services
  2. Database
  3. SSRS Reports
  4. SSIS Packages
  5. Who knows what else

I like the fact that I can give the workflow some basic parameters like which build to deploy and it would just run. Potentially, some parts might need human approval, and I know that workflow can handle that too. An example is that we might use the workflow to create a change script from our Visual Studio Database Projects, but the DBA group will want to approve the script before it is run.

I'm interested to know whether others have used "builds" for this in the past, and what problems were found.

share|improve this question
    
We're using TFS 2010 to manage our builds/deployments. I don't have any quick answers for you; but as issues come up feel free to email me and we can at least try to figure it out. –  Stephen Gross Oct 28 '11 at 18:35

1 Answer 1

up vote 1 down vote accepted

We've used TFS to trigger our builds but used msbuild to build our projects. The main advantage is that we have a build script that we can change an keep under version control. Thing is with workflows e.g. : how are you going to build an older version of your project? With a build script you just get the older version from source control and off you go. It's also nice to be able to fiddle around with it and switch different options on/off.

If you're dead certain you have a fixed build cycle, then you probably can pull it off, otherwise having a script is probably the safer and more felxible option.

share|improve this answer
    
The workflows are .xaml files stored in source control. I will need a process that branches the .xaml files along with the source code. No doubt you branch your msbuild files along with the source. –  John Saunders Oct 23 '11 at 19:24
    
@JohnSaunders yes, we do branch our build scripts. It's cool that the configuration of your workflow is stored in an xml file but what influence does changing the configuration have on items that are in a different version of your workflow (workitems, tasks etc. within your project also are within that same workflow right?) That's where I see a risk, changing the behaviour of how TFS handles your project on the fly. –  Carlo Kuip Oct 25 '11 at 8:41
    
I don't know what you mean. Changing the build process template won't change work items. What do you mean "items that are in a different version of your workflow"? –  John Saunders Oct 25 '11 at 12:55
    
The process template that you apply when creating a TFS project is creating a workflow. That means that if you create a workitem it is linked to the various stages of that workflow. Is your build proces going to be an extension on that workflow or is it a seperate one? –  Carlo Kuip Oct 25 '11 at 13:04
    
Sorry, you're confusing a process template and a build process template. Microsoft chose their terms poorly. Also, the process template you use when creating a team project does mot create any waorkflow that I'm aware of. –  John Saunders Oct 25 '11 at 13:06

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.