In "Managing production Notes deployments," I described a lot of steps, which take time and effort to do and get right, and which often need to be done out of hours, which then adds to cost. This is where Teamstudio's Build Manager product comes in.

Build Manager is intended to provide their customers with something that enables Notes application changes to be pushed along a path from development to test and from test to production, with whatever nuances of environments that exist, and do it in a consistent and error-free manner. As we've seen, this isn't a trivial operation, and should not be perceived as such.

Now, I'm not going to do a traditional, detailed review of Build Manager here, for two reasons that are intertwined in each other. The first is that it's a complex piece of software that requires careful setup and configuration, as well as integration with your development process. That requires time, effort and several environments to do properly.

Secondly, whatever environment I had will be different to yours, which means that what works well for me may not be what you need. So what I did instead was talked to Teamstudio's Technical Director, Simon Peek, here in the UK about how Build Manager works and how you get the best from it.

Simon explained to me that Build Manager is now sold as a configured option only. So the price you pay includes not just the software, but also on-site time from TeamStudio to get it set up to do the things you need it to do and ensure that you will be getting the best from it. And to make that simpler, they've also changed the licensing model so that your price is now based on the number of people who will actually use it, and not on the actual number of Build Manager components installed.

Build Manager is a Notes application
Build Manager itself is a Notes application. If you have CIAO!, then the Build Manager configuration database replaces the CIAO! configuration, with Build Manager replacing the promotion parts of CIAO! In the configuration database are defined the rules and actions that define how applications are to be managed, and including such things as stored Notes ID files that are used to do the actual signing of applications.

These rules and actions are defined on a database-by-database basis. You use the ACL of the Notes database, including Roles, to define who can do what with that instance of Build manager. You may have more than one instance of Build Manager in place: one that pushes -- promotes -- applications from Development to Test, operated by the development team leader, and another that promotes from there to Production, done by a Notes Admin person.