If you’ve built or maintained software applications in just about any other development environment, you’ll be familiar with the concept of build automation. The concept is straightforward: you specify the steps needed to build your finished application from its component parts, and then automate those steps so that they can be executed consistently each time a new version of the application is built. Most applications are composed of a number of different pieces that need to be assembled in some way, and it really helps if you can ensure that the same build steps are followed consistently each time.
But what does build automation even mean in the context of an HCL Notes and Domino application?
If you’re used to working in the Domino environment and you’re maybe not so familiar with traditional build processes, it might help to think in terms of the movement of Notes design templates from one environment to another. For example, you may have a test environment that is separate from your development setup. Both of those are kept apart from the production environment. Build automation, in the context of Notes/Domino, can be thought of as a way of carefully controlling the movement, or promotion of templates from one environment to the next.
Teamstudio Build Manager is a tool that does just that; it controls the movement of Notes database templates from one environment to another. It improves efficiency by automating the steps necessary to make a template ready for the next environment, and reduces risk by making sure that all necessary steps are completed as specified, thus reducing the risk of human error. It helps with compliance to regulatory standards by ensuring the enforcement of segregation of roles, and it does all that at the push of a single button! Whether you’re an HCL Notes administrator or developer, it makes your life easier by allowing one-click builds.
The Promotion Process
Build Manager allows you to create promotion path documents, which define how a template is created and automatically promoted through the process to production.
The time it takes to actually do the promotion varies and is contingent upon the size of the design being promoted, and the network bandwidth. The promotion process starts with creating a backup copy of the existing code to be used as a rollback if the promotion fails.
A Technical Look at Teamstudio Build Manager
There are six components to Build Manager: four NSF files, an executable file, and a DLL file. The code is run from a Notes client, so only the database is installed on the server. The executable and DLL files are installed on each PC that’s being used to run Build Manager for promotions. Build Manager users need to have sufficient access privileges to be able to write to the Notes and Notes Data folders. The four .NSF components are:
The Build Manager Configuration Database is required and holds all configuration and build documents.
The Template Registry Database is optional, stores all versions of code promoted out of development, and is the staging area for promotions to QA/UAT/TEST and production environments.
The Workflow Approvals Database is optional and is used to configure approval workflows when approvals are needed to promote code to the next environment.
The Agent Parameters Database is optional and is used for the "run agent" step that is described below. It takes information from the configuration documents and provides them as easy-to-access variables to be used in LotusScript agents as part of the build.
The key actions you can automate using Build Manager are detailed below:
Build Path: This step allows you to define the template registry the template will be stored in.
Promotion Path: This step allows you to define where the template will be placed so the target application can have the design automatically refreshed/replaced.
Make Version: Uses details from the Teamstudio CIAO! configuration document (if you have licensed a copy of that product) to create new versions of the application.
Design Audit: Uses Teamstudio Analyzer auditor (if you have licensed a copy) to search for design issues and report on them relative to failure thresholds.
Search and Replace: Uses Teamstudio Configurator (if you have licensed a copy) to perform an automated search and replace on the target database to identify and change text in the promoted template as part of the build.
Database Properties: Automatically changes the following database properties: Title, Categories, Inherit From, Template Name, TemplateBuild.
ACL: Automatically sets ACL properties and roles using values either defined in this step or derived from a Stored ACL.
ACL Entry: Automatically adds ACL entries (people and/or groups) to existing ACLs.
Copy Database: Automatically copies the target database to another location.
Compile LotusScript: Automatically compiles all or specified LotusScript in the design.
Element Properties: Automatically changes the following design element properties: Prohibit Design Refresh, Propagate Prohibition, Design Element Inheritance, Design Element Comment.
Enable Agents: Automatically enables or disables the selected scheduled agents.
Set Agent Server: Automatically sets the server on which the agent runs for the selected scheduled agent(s).
Set Agent on Behalf of: Automatically sets the user the scheduled agent will run under.
Refresh Design: Automatically refreshes/replaces the design of one or more databases. There is an option to ignore any prohibit flags in the database to be refreshed so you can ensure the design in the target is that same as the design that passed testing.
Run Agent: Automatically runs any agent in any database. This step allows for custom promotion processes that include steps not defined as standard in Build Manager.
Sign Database: Automatically signs the database from a stored or attached ID. The options are the same as if using the Administration Client.
Email Notification: Automatically sends an email to one or more individuals or groups when the build is successful.
These steps are configured to match your existing processes, so all of them may not be necessary.
Just looking down this list of actions highlights the number of things that are done as part of a “build” process for a typical HCL Notes/Domino application. If you control this process in any way (checklists, for example), then we’re going to say you’re way ahead of most other people. Typically, this process is dependent on some poor person’s memory to make sure that everything happens in the right order, consistently with each build.
If any of this sounds familiar, you might want to take a closer look at Build Manager. If you’re in a regulated industry or have corporate standards that cover things like this, it could really help make your builds more consistent and improve the quality of your finished applications.