Understanding Build Manager Promotion Paths: The Key to One-Click Builds

By Nigel Cheshire

It's no secret that one of the key features that contributed to the success of IBM Lotus Notes back in the 90s was Rapid Application Development (RAD) - the ability for the "citizen developer" to easily and quickly build a useful business app. That resulted an many simple applications being written, but didn't stop many other, more complex apps being delivered on the Notes/Domino platform. The addition of LotusScript, and later Java and JavaScript to the development environment led to more and more complex Lotus Notes applications being written. 

That trend was what drove the development of our source code control solution, Teamstudio CIAO!. In fact it was the Lotus team responsible for creating and maintaining the core application templates, under the leadership of Rich Bernardo, who worked closely with us and inspired us to create that product. In that case, they had a team of 10+ developers who were potentially working on the same application template at the same time.

As the complexity of applications (and with it the development environment) increased, we saw the need for tooling to help manage the build process - that is the process of assembling all the parts that go together to make a completed application and then moving it to its desired location. For many "power users" who were building simple discussion-based applications on Notes, the concepts of source code control and build management would have been a complete mystery. Which is partly, I think, why Teamstudio Build Manager is one of our most valuable, yet least appreciated tools.

Although the days of large Notes development teams are long gone (for now), anyone who is still maintaining Notes applications should take a look at Build Manager. That may sound like a bold claim, but if you create or maintain Notes/Domino applications, and you deliver them to users, then you have a build process, whether you know it or not. Of course, the simplest "build process" is the case where you take a new version of a design template and apply it to a live application by using "Design Refresh". But there are likely other steps that you take too, for example:

  • Set ACLs - You may need to review and set ACLs on the production database.
  • Database Properties - You may need to set or change the database title, categories, inherited-from template name and master template name. Also, you may need to update version information such as the template version, name and date.
  • User Visible Version Info - Some applications have a version number that is visible to the user and can be helpful for support purposes. You will need to update it.
  • Set Agent Server - If you have been testing the app on a different server, you may need to change the name of the server that scheduled agents are set to run on.
  • Sign Database - You may need to sign the database or specific design elements with a particular Notes ID.

In many (most?) Notes/Domino development environments, these items are done manually. I'm hoping that there are checklists that are used to ensure that the steps needed to perform a "build" are done consistently, but I'm guessing that in many cases they are not. I'm sure this has never happened to you, but I have heard of instances where one or more of these items are forgotten, or performed inconsistently, resulting in problems for users down the road.

The promise of Build Manager is a "one-click build" - the idea that you can define all the things that you need to do to move your application design from (say) development to a test environment, or right into production, and then perform them, consistently every time, with a single click. 

So back to the title of this post. What is a Promotion Path? Simply put, it's the definition of where the finished application should end up. There are three types of configuration document that control the Build Manager setup:

  • Database Documents define where the source template is located. If you are using CIAO! for source code control, this document is also used to configure how CIAO! controls access to the template.
  • Promotion Paths define where the finished built template will be located and what the build steps are to create it
  • Build Paths are identical to Promotion Paths, except that the finished template location is in a template registry, which is used to store and track versions of different templates.

The word "promotion" is used in the term Promotion Path because it is usually used to "promote" a template from development to test, or test to production.

So that's it. A Build Manager promotion path is right at the core of the product - it defines the steps used to build the template and the location where the finished template should be placed. One of the steps, by the way, can be the design refresh or replace action, and so Build Manager can truly be used to deliver consistent, one-click build and deployment of your versioned templates, significantly increasing the quality of the application deployment process. 

You could argue that every IBM/Lotus Notes/Domino application development team should be using Build Manager to manage their application updates and deployment (we would!). If you are managing an environment that includes Notes applications and you'd like to talk about how Build Manager could help, click below. We're always happy to chat!