Deployment best practices

Here are deployment best practices, many of which are particularly important in enterprise environments that have many thousands of users.

  • Create a Domino server test Environment. This step allows you to test the new version outside of the production environment.
  • Piloting the upgrade in the production environment with a small set of users. This step allows you assess the impact on a small set of users before deploying more widely.
  • When upgrading software, consider following the principle of stepwise upgrade, whereby at each step of the process, you are able to back off to the previous step until you are confident in the current step.
  • In the early stages of the new deployment, make subsequent steps small enough in terms of change and the number of Domino servers involved to allow you to back out to the previous step, if necessary. This approach also allows for incremental optimizations for your environment. As more Domino servers are upgraded, and confidence increases, enterprises usually increase the rate of change and size of the steps.
  • Choose one or a small number of Domino servers for the first step of the upgrade process. If possible, when picking these servers try to strike a balance between their being representative of your production environment yet involving less business risk. The configuration and tuning of these servers can be a model for the broader deployment.
  • Set success criteria for each step in the upgrade process. One set of criteria should relate to CPU, virtual memory, read/write operations. You can add other criteria that you choose. Monitor these operations for several days before and after the upgrade and investigate any significant differences that are unaccounted for by component changes in the new Domino version.
  • Enterprises with passive Domino failover servers should consider deploying one of these as a first step, to further reduce risk.
  • Wise use of existing failover architecture can also reduce risk during upgrades. Some enterprises, for example, delay upgrading both pairs in two-way clusters until all of one side is upgraded. If a problem occurs with an upgraded server, failover to a clustermate is a possibility with high probability of success. Consider upgrade of the Active side of Active/Passive pairs first. This enables deployment on production loads, while preserving the failover opportunity. Larger enterprises also do well to consider a production failover test to validate previous hardware sizing assumptions for clustermates. Failover test criteria should also include monitoring.