Sponsors

Microsoft


TechWell

We have 1892 guests and 3 members online

Home Product Reviews BuildForge Puts Your Build Processes in Your Control

BuildForge Puts Your Build Processes in Your Control

E-mail
Written by David Baird   
Thursday, 07 October 2004 16:00

I really enjoyed working with BuildForge, and the more I learned about it, the more ideas I had for applications in the projects I support. I've been maintaining build processes for the past 15 years. I tend to focus on creating make files, and have learned several flavors. I also incorporate Perl scripts and push the limits on fully automating everything. The first thing I liked about BuildForge was that it puts a pretty and unified face on a projects build processes while not forcing me to change anything in our current make files and scripts.


Servers, Projects, and Activities

The BuildForge Architecture is made up of an unlimited number of server Agents and a Management Console. The agent is easy to install, but for most Unix flavors, including Linux, you will have build and install it from source files. The Management Console must be installed on a Windows machine.

The BuildForge Management Console

Click to show larger image

One must define build servers, and each server definition must have a user login and password specified. This requires you to define specific users in your environment which will run the automated build processes. You cannot let the BuildForge user select their own user logon to run the build activities.

The BuildForge projects are a set of steps, which can be run in serial, organized so groups can be run in parallel, or run simultaneously on a pool of servers. The projects can be organized so that several can be run in series, parallel or included as a build step. In this way, projects are best thought of as build procedures. One can define a build procedure to run steps on several types of servers. I used this to define a single build procedure which created an RPM file on Linux, but required previous make commands run on Linux and Windows build servers.

BuildForge has many built-in commands for copying files, creating zip files, and importing or saving the BuildForge environment and procedures in an XML file. This last feature allows you to save the BuildForge build process in your version control, and at a later date reproduce the build process.

The BuildForge activities are the execution processes which can be started manually or scheduled automatically. Each activity is given a tag identifier, and the output of the build procedures are saved in the BuildForge interface. You can define filters to detect errors and warnings, and send email when they are found. You can also view the actual and total execution times, which will be different if you've defined parallel build steps and procedures. There are also a small set of reports you can view, like a report of version control changes and a comparison of build times. You can create more reports by accessing the BuildForge database tables outside of the Management Console. The tables are documented.

Security

BuildForge has a strong set of features for defining users and permissions groups. This allows one to limit the build activities and build servers a user has access to. If you use LDAP for user authentication, BuildForge can be configured to utilize it. However, it won't import user information from an LDAP server.

Feature Oriented Interface

The Management Console is accessed through a web browser. On the whole, I like web based applications for controlling build procedures. I have a web based change management tool, a web based product lifecycle tool, and a web interface for my version control tool. I did find the implementation of the Management Console to be difficult to navigate. Perhaps this is because I was setting up a build project from scratch. Once I got my build project setup, I found it easy to fire a new build activity.

Still, it would be nice if the interface were less tied to BuildForge's features, and more to the tasks involved in managing the build projects. Moving from the server definitions to the project definitions should be better planned. The interface was not helpful in understanding the relationship of the environment variables to the server, project and build steps, or version control to the scheduling. The concept of threading build steps and pooling them on several servers are very useful, yet well hidden, features.

Version Control Integrations

I worked with the ClearCase integration. The provided me with two features. The first is the ability to run build steps in a ClearCase dynamic view by specifying the view name through a CLEARCASE_VIEW environment variable. The second is to schedule a periodic build activity, and make the execution of the activity dependant on changes in the version control archives as seen through a ClearCase view. I found the interface essential to allow me to run build steps in a view. There were a few challenges running build steps on Windows in a view drive rather than the M: drive, but was able to overcome them by using another special environment variable, _MAP.

Great for Distributed Teams

One application of BuildForge which became immediately obvious to me was the ability to allow remote developers and teams to run their build processes on controlled and powerful servers are their home office. This can also assist off-shore development groups who could remotely access a version control tool, and then run their builds on their parent company's servers. I spend a lot of time replicating build environments at our Israeli location for team members of large American based projects. My job would be a lot easier if I could provide a BuildForge interface to a couple of servers in America to run our builds, and we would have more confidence that our code changes would work in the official project environment.

Support

The support team will do all they can to ensure that you succeed with your implementation of BuildForge. They will setup a web meeting with you to walk through the Management Console and demonstrate many of their advanced features. During my walk through, I was able to discuss ideas of how I could take advantage of their features and got very detailed technical advise. Their walk through is an essential part of understanding their product and how it ideally works. I felt that the people I spoke to had a very good understanding of their product and how to respond to a variety of situations.

Documentation

Read the documents, read them again, then again. I don't know why all the useful information in the PostScript documents isn't accessible online from within the Management Console. There are static help messages at the bottom of every screen, but they serve as hints rather than instructions. I didn't find a wizard or a step by step guide, which would be very helpful. Even a link to the BuildForge support page would be a simple and very useful feature. I didn't see any documentation for the new ClearCase integration, which I tested quite a bit, although I did find the support team helpful and answered my questions.

Ameri-Centric Product

I don't live in North or South America. I really take notice of products who seem to forget about customers outside of the four North American time zones. BuildForge is a relatively young company, and I've dealt with several others with a localized distributor, if not European and Asian support offices.

One particular feature where this Ameri-centricism is obvious is time zone selection for displaying build activity start and stop times. There are no time zones listed outside of North America. Sure, I can add them in a configuration file, but is it really that difficult to provide all 24 GMT offsets, at the very least?

Company Background

BuildForge has been in operation since 2001, so they are not a large organization with many products to support and maintain. They have, however, established themselves as a leading provider of build management software. I view this as an advantage as they are focused on making their product succeed. The current feature set and future plans are linked to responding to their customers' needs. I hope their product expands into other areas of the software construction process, in particular product artifact release management before and after the build procedures.

Costs

The price for BuildForge 3.5 starts at $25,000 US. Pricing is based on the Management Console plus concurrent seats. Enterprise licensing options are also available.

Company

BuildForge, Inc.
3925 W. Braker Lane
Suite 3.110
Austin, Texas 78759
Phone: +1(512)305-0737

sales@buildforge.com
http://www.buildforge.com



David Baird has been a programmer, buildmeister, and general software toolmonkey. He works at Qualcomm Incorporated as a software development processes engineer. David's background includes work at various software communication companies in Israel and California. At the age of five, he was known to add crayon drawings to his father's punch cards.

You can reach David by email at
david.baird@cmcrossroads.com.

Trackback(0)

Comments (0)add comment


Write comment

You must be logged in to post a comment. Please register if you do not have an account yet.

busy
Last Updated on Thursday, 12 January 2006 04:30