The term “build” is one that has been used in the software engineering profession for decades, but is rarely heard around the IBM Notes/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 rapid application development environment, based largely on interpreted script languages, means that for many, the concept of “building” an application is a foreign one.
As as a Notes/Domino professional, why should I care about build processes? Well, assuming we want some level of control over managing changes to production applications (in other words, we 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 you might think.
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
We may have to take different actions depending on our promotion path, for example whether we 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?
Well, 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, we find 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.
In summary, if your work includes maintaining Notes/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.