How to build TEST environment of Lotus domino?

Solution 1:

In the Notes/Domino environment, a "domain" is defined as a set of servers that share a common names.nsf. I.e., their names.nsf databases have the same replica id.

That means that if you want test and production to truly be the same domain, you want a one-way replica of names.nsf, not a one-way copy. This can be done, of course, using ACL permissions and/or selective replication settings, but it is dangerous, and not recommended.

The most basic problem is that every single method of setting up one-way replication can be accidentally or purposely gotten around, resulting in data leakage from test back to production. Most commonly, this happens if an administrator accidentally triggers a manual replication from a client. Because of this, I cannot recommend doing it. You will almost certainly have leakage from test into production if you really have the servers in the same domain.

What you can do is make them look like they are in the same domain, but not actually be the same domain. In fact, you would want all critical databases in your production domain to explicitly limit all servers in the test domain to Reader permission, and you would want the equivalent databases in test to be non-replicas in order to reduce the possibility of accidents.

You could do this by making a non-replica copy of names.nsf and setting up a mechanism to periodically (say, every night) re-copy all documents from the production names.nsf into your test names.nsf, overwriting any changes. A very simple LotusScript agent could do this. This would load up your test names.nsf with lots of deletion stubs, but there are ways around that. A slightly more sophisticated agent could avoid deleting and re-copying by matching production UNIDs to an added saved item in each test document and simply re-copying the items. An even more sophisticated agent would store an additional item in test with a hash of all production item values in order to avoid re-copying items when there is no change. And, of course, over the past 30 years there have been a third-party tools developed that can do Domino-to-Domino data synchronization, and some of them are still supported.

Even all this, however, is still a bit dangerous. Even if your names.nsf is a non-replica copy of production, it will still have all the same connections that production does. This means that it can send emails exactly the same way that production can, and they will look like they come from production. There are steps that you can take to prevent this crosstalk, but what you really want is for emails to go to test environments (either within the Domino test infrastructure, or non-Domino test systems). You can't really do this without modifying documents in the test names.nsf so that they no longer match production.

The best practice, IMHO, is a separate test domain whose servers ids are certified with a different root certificate than production, with synchronization of users and groups only, with only authorized test users cross-certified to access the test domain (and/or configured for browser access) and very careful management of the differences in configuration to prevent leakage and crosstalk.