using BuildForge to Build and Deploy .Net applications

Question

I have been working to get applications that I support to be built and deployed more automatically than manually. My team uses RTC to store code (not my choice, If I had a say we would use TFS, or hell, Subversion), apparently they use Build Forge to build and deploy Java applications. From my understanding, buildforge simply orchestrates everything and runs scripts to perform the actual build and deploy tasks.

Now, I have been working on powershell scripts to build my code and deploy it. I can't seem to find any information online about how to actually integrate anything that I have already done with this tool? Just alot of fluff pieces from IBM about how great there tool is?

Is there a good tutorial anywhere about automating a .net application with BuildForge?

Answer 1

That's exactly why I don't like BuildForge. It's a great cross platform, multiple host orchestrator but it doesn't really "build" anything. I spent several years at a company where we had around 800 projects on one server and another 800 on another. We found that if we wrote all of our build steps into BuildForge that we'd kill the database. So instead we had a common library that did most of the work by calling out to NAnt. MSBuild would have been a good choice also but at the time NAnt was more mature.

We ran 100,000 build a year on 60 virtual machines. We had a build step that talked to the VSphere server to reset the VM, wait for it to come back online and then run the build on it.

I also worked for another company that used AStarTeam for source control and BuildForge for builds. I stood up a TFS server and write a Get extension to pull code from StarTeam. I then created BuildForge projects that wrapped the TFS build. As far as the developers knew they will still using ST and BF but in reality I was getting all the Workflow/MSBuild capabilities of TFS with the possibility of them moving the source over one day and being all TFS.

So ya, there is no one tutorial for .NET on BF because it's all on how you want to do it. Perl, PowerShell, NAnt, MSBuild et al.

Answer 2

The problem powershell and BF is how BF captures the output. the agent captures the posix equivalent of stdout, but powershell does something strange with output handles and the output isn't funneled back into the agent properly. As a result, there is no output back to the agent and the step times out. There were fixes made to the console code in the 7.1.3 line that may prevent the step timeout from happening (the agent wasn't sending the heartbeat back to the console correctly in some cases). If not (I'm not a powershell user) then there are ways around that with wrappers, but it's not obvious nor trivial.

And yes, BF is a great multi-platform automation tool, but it's only as good as a build tool as you make it. It comes with the pieces and documentation to do real CI against several different SCM systems. The conditional steps also make it unnecessary to use adaptors to do real CI with BF at all. It has all the pieces to make it a great build tool for (just about) any environment.

source: I'm the build engineer for the BF product.