It's no secret that one of the key features that contributed to the success of 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. (These days, of course, we call it “low-code”.) That ease of building simple applications resulted in many such apps being written, but didn't stop many other, more complex applications being developed on the venerable Lotus Notes platform. The addition of LotusScript, and later Java and JavaScript to the development environment led to more and more complex Notes applications being written over time.
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 who worked closely with us and inspired us to create that product back in 1996. In their case, Lotus had a team of more than ten developers who could potentially find themselves working on the same application template at the same time.
As the complexity of applications (and with it the development environment) increased, we here at Teamstudio saw the need for tooling to help manage the build process, by which I mean 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 I consider Teamstudio Build Manager to be one of our most valuable, yet least appreciated tools.
Although the days of large development teams working on “traditional” Domino apps (i.e. using Domino Designer) are probably behind us, anyone who is still maintaining those applications should take a look at Build Manager. That may sound like a bold claim, but if you create or maintain Domino applications, and you deliver new versions of 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?) HCL 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 from one build to the next, 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, and how it gets there. 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 (if not, why not?!), 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. Within Build Manager, you can set up action steps such as the ones identified above (e.g. set ACLs, sign database) and then use those steps in a promotion path to define the build process itself. The promotion path defines the location of the component pieces, the action steps that are carried out to complete the build, and the target location of the finished application.
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. If you want to dig into more technical detail on how Build Manager works, feel free to browse around the Build Manager technical documentation.
You could argue that every HCL 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 Domino applications and you'd like to learn more about about how Build Manager could help, click below. We're always happy to chat!