The term “build” has been used in the software engineering profession for decades, but is rarely heard around the HCL Domino world. The concept of compiling source code, adding runtime libraries and then assembling the whole thing into a finished executable file is as old as the concept of “high level languages”, and many tools have been built whose sole purpose is to manage the build process. But in the Notes/Domino world, the nature of the development environment, based largely on interpreted script languages, means that for many, the concept of “building” an application is a foreign one.
So as as a Notes/Domino professional, why should you care about build processes? Well, assuming you want some level of control over managing changes to production applications (in other words, you don’t just go edit code in a live application on a production server), there’s usually more to creating a new version of a Notes/Domino app than anyone might imagine.
Just think for a minute about some of the things that you routinely have to do when you roll out a new version of a database template into production:
Set database properties
Set correct ACLs
Compile Lotusscript and check for errors
Set design element properties
Enable agents
Set which server to run agents on
Sign database with correct ID
You may have to take different actions depending on your “promotion path”, for example whether you are promoting the application from development into test, or from test into production. Many of us just execute these actions manually, without giving them much thought, and in many cases without even documenting them. So what’s wrong with that approach?
From our experience of working with clients, if the build process is not written down, different people do it in different ways. Some people miss some steps because they didn’t know they had to do them. Or just forgot. Even if it’s always the same person that executes the build, if the steps are not written down, it’s easy to miss something or just do something differently each time.
Also, our experience is that most Domino administrators spend way too much time fighting fires, not to mention the constant stream of requests that are coming from management and users. A little time invested in defining a robust and repeatable application deployment process will pay dividends down the road in terms of saved time not having to track down problems with applications not working as intended.
Another benefit, of course, is that creating, using and documenting a standard deployment process gives you a layer of auditability, something that is very important in regulated industries.
Writing the steps down and carefully following them each time an application is built is a great first step toward getting the application deployment process under control. But a much better approach is to use a tool that allows you to automate the whole process and truly eliminate human error from it. A tool also gives you the benefit of taking care of the audit trail for you automatically.
“Make", of course, is the grandaddy of all build tools, having been included in the original Unix back in the mid-70s. Many, many build, and more recently continuous integration tools have followed on from Make, but only one build automation tool is specifically designed for working with Notes/Domino application designs. Teamstudio Build Manager lets you define standard actions as part of your Notes/Domino application build, that are applied automatically and consistently at the click of a button.
If your work includes maintaining Domino applications and/or rolling new versions of database designs out into production, then it would benefit you to think carefully about the “build” or promotion process. If you don’t already have a carefully defined and documented build process, then you should consider creating one. If you’re interested in truly automating the process to produce consistent, auditable builds with minimal effort, then you should take a look at Teamstudio Build Manager.
To learn more about Build Manager, click below.