By Larry Barker
The release of HCL Domino v12, combined with Teamstudio Build Manager v9.0, opens up some interesting possibilities for using new features in both products to integrate HCL Domino apps into DevOps strategies using modern platforms and tools. This is the second in a series of articles that describes some options for how to do that. The first article is here.
To understand how we can take advantage of Teamstudio Build Manager to enforce and support Domino DevOps practices in conjunction with a modern hybrid or cloud-based infrastructure and as part of a broader release management program, we first need to understand the basics of Build Manager’s approach to build and release management.
Pipelines and Promotions
In a nutshell, the problem we are trying to solve is that we have Domino applications and templates in need of well-structured and repeatable release processes. These may be referred to as pipelines, builds, promotions or deployments.
Build Manager allows you to define build and deployment processes for your Domino applications. What we refer to as promotion and build paths are often called pipelines in other environments. These pipelines or promotion paths consist of a series of defined, automated steps with the goal of preparing a template for a specific release environment. In addition, this also includes all control and auditing mechanisms that may be required along the way.
Build Manager has a feature referred to as the Template Registry which allows you to decouple your Domino application deployment and development processes. That allows developers to continue working on the next exciting feature while the Release and Deployment teams are able to get on with managing the release process. The Template Registry is essentially a database where different versions of templates can be stored, tracked and managed.
In the diagram above we can see what an example series of Build and Promotion paths which move our application through various stages might look like.
1) Build Path: Dev01 to Template Registry
Build paths are typically used to move applications from Development to Template Registry, or directly to a target Domino server.
They are comprised of a series of “Build” orientated steps that will bundle/prepare the application for the next stage.
Example Build steps used within Build paths may be Make Version, Compiling LotusScript, Application Design Analysis/Audits, NSF to template conversion, and Release Approvals
Once all build steps are completed, multiple versions of a template may be stored within a staged container (fully customizable) within the Template Registry.
2) Promotion Path: Template Registry to Test01
Promotion paths are used to transition and prepare applications for a specific operational environment, usually a target Domino server.
Typically, steps are orientated towards release tasks that ensure the application is properly prepared for and located within the target environment.
Common “Promotion” steps may be agent management, signing of production code, refreshing inheriting databases or design replace, bootstrapping an application with test data, or any number of other steps.
Once the application has been deployed, all approvals, release steps, and notifications are logged and processed.
3) Template Registry: Stage Approval
You may customize any number of stages or Template Registry instances to manage your release process.
In the above example we can see that once testing, or any phase, has been completed you may initiate approval for the specific version of your application to be available for release into the next environment.
With up to 5 configurable approvers, once signed off this template is then available for use in Production and deployed as/when administrators require.
Multiple versions of a template may be available at any one time for promotion into the environment. For example, you may at any one time have the current Production version as well as any new application changes available which ensures there is a rollback point in place should you need to roll back any deployed changes.
4) Promotion Path: Template Registry (Production Staging) to Prod01
Production-based promotion paths will pull templates from any staging-oriented container within Template Registry and run any build steps needed to prepare it for the production environment.
Usually steps within the production release will be performed using a secure promotion ID stored within Build Manager enabling admin-level build actions while protecting the environment from Admin ID misuse.
Because promotion into Production is such a critical step, you may usually see not only promotion steps that would appear in a promotion to test, for example, but more security-related actions as well such as signing agents/code with role-based IDs or setting template ACLs.
Once completed all release actions will have been logged, release and approval notifications processed and logged available for future auditing.
Deployment Build Steps
To get down to the nitty-gritty of defining your Domino deployment pipelines, you need to understand the build steps that comprise them. Of course, one of the most interesting aspects of being able to automate and define your deployment tasks is understanding how to use and sequence the steps in a way that brings about controlled, auditable, and efficient releases. The end result is the realization of benefits that will make a world of difference in terms of release quality while avoiding common mistakes along the way if performed manually.
For a quick snapshot of what is possible within your Build and Promotion paths please see the figure below, or refer to the Build Manager Build Step documentation.
But what about Version Management?
This is really a conversation for another blog post. Build Manager builds upon code control and version management beyond your development environment to ensure versions released from development maintain their integrity throughout the build and deployment process and on into their desired destination. This capability also comes in very handy when under the pressure of a roll-back scenario should this unfortunate situation ever arise, enabling one-click recovery to any previously released version of a template. To learn more about Version Management in development please refer to our CIAO! Product and for more information about how Build Manager augments this beyond development please refer to the Make Version step documentation, and/or the Template Registry introduction.
What’s Next?
Now we have a basic understanding of what’s behind application promotions under the direction of Build Manager. In our next DevOps for Domino post, we will take a more granular look at some of the specific steps we may use to take advantage of AWS Infrastructure as Code options to deploy purpose-built on-demand Domino servers for testing application releases. Further, we will explore using Build Manager to bootstrap a Domino application with our desired configuration or test data in conjunction with the application release.