3.1 Using development, QA, and production servers 

Previous | Next

Domino  environment

Domino provides a rapid application development environment, this does not mean that one should ignore standard development practices. There should be at least a separate production environment and development server, even if there is only one developer.

The normal Domino environment consists of a development domain, user testing or quality assurance (QA) domain, and the production domain . The access rights a developer has changes with each domain.

The ultimate environment has the development domain and the QA domain be an identical configuration as the production domain. This in reality is cost prohibitive, so the next best setup is to have the QA domain match the configurations in production that would likely cause issues. If in production you have internal application server and servers with web access that are available to third party over the internet hosted on a secured access zone or a demilitarized zone (DMZ), then the QA domain should model that structure. The idea is to be able to test the application fully so it will not have issues when moved to production. At this point you are trying to match the overall configuration of production, not that actual setup. If you access a relational database management system (RDBMS) in production, then you must have the same access in QA. If you have five application servers in production, it does not mean that you need five for QA.

Because you do not hard code server names into the application, as that would be a really bad practice, developing your application on a different server is not an issue. If you have code that accesses another database on a different server, then the target server's name should be on a profile or configuration document that can be easily changed. There is an application on OpenNTF.org that can help you maintain these configuration documents if you have a large number of applications that interact. The application even supports failover when a server is down.

This figure shows what the Domino environment looks like from the server prospective.


The management of the flow of the code between the areas can range from a simple Notes database to utilizing a third party tool to control the templates. What is the most important rule is that you have a procedure and follow it.

Development environment

The development server can be anything from a single virtual machine (VM) running on the developers workstation up to multiple servers. This is the area for developers to build and test the applications. If you are doing team development then the Domino development server has to be on hardware that can be accessed by all developers. We discuss virtual machines and how they can be used to help with development and testing in 3.2 Multiple version support with virtual machine.

For the development environment, it should be set up to allow the developers to easily change the configuration to assist with developing the applications:

• One or more developers should have the basic Domino Administration skills.
• Developers have manager access to server and applications.
• Developers use the Lotus Notes Administration Client to:
• See view information.
• Use server console to check for errors.
• Developer must be able to create databases and replicas on the server.
• Developers can change Domino Directory documents such as the Internet Site documents.

The server configuration should have:

• No connection docs unless there are multiple development servers.
• Mail routing turned off, you can access the mail.box to see what messages look like. User can get confused by notifications from the development server.
• Developers have full access to the server's mail.box.
• If the production servers use SSL, then development should have at the minimum a Domino self-certificate.  With the cost of SSL certificate running under $100, it is cheaper to purchase one then have to deal with the administration of the self-certificate.

The server can be in the same Domino domain as production or in its own domain:

• If in the same domain:
• The Domino Directory is a copy of the main production domain so no chance of replication or It has its own copy and the production Domino Directory is set as a secondary address book using Directory Assistance.
• Give the development server a different Notes Named Network, so users do not see it.
• If in a different domain:
• The main production Domino Directory is set as a secondary address book using Directory Assistance.
• Cross certify the development domain to the production domain to make it easier for everyone.

QA and user testing environment

Developers should have, at the most, the designer access if they are allowed to make minor code changes to QA, otherwise, they have the same access as they do to production.

The Domino QA server configuration should match as closely to production as possible. If you have an internal Domino application server and a separate Domino server for web access in production, then you should have the same in QA.

The server can be in the same Domino domain as production or in its own domain:

• If in the same domain:
• The Domino Directory is a copy of main production domain so there is no chance of replication; or It has its own copy and the production Domino Directory is set as a secondary address book using Directory Assistance.
• Give the development server a different Notes Named Network, so users do not see it.
• If in a different domain:
• The main production Domino Directory is set as a secondary address book using Directory Assistance.
• Cross certify the development domain to the production domain to make it easier for everyone.

The build process

Use templates to move the design between environments.

Development to QA

The steps a developer takes to promote an database from development to QA are as follows:

1. Create a template from the development database.
2. On the template database properties, Select Database file is a master template and enter the template name.

There's no fixed rule as to whether the template name should include a version number (e.g. TPL Quality Info v1.2). Usually, applications undergo continuing maintenance. If your intention for the application is that every instance of the application will have the same design, receiving updates from a single common template, it's better to not put a version number in the template name. That would just make it harder to maintain the design of the application across all instances.

However, if you intend that there might be different versions of the same application on the same server, it may make sense to include the version number in the template name. This might be the case if you're developing your template as a product to sell, for instance. Different customers might deploy different versions within the same company, and you wouldn't want to have older versions automatically upgraded by the DESIGN task because someone installed a newer version of the template on the server -- especially if there are data updates that should happen at the same time as the upgrade, or if the users of the application might have older clients that don't support some features used by your new version.

If you do put version numbers in your template names, make sure the different versions of your template are not replicas of each other. This can lead to older version templates being overwritten by the newer version through replication, and occasionally can result in duplicated design elements in both replicas (if the design elements with the same name didn't have the same universal ID). This causes a huge mess.

If you don't want to put the version number in the template name, but you still want to have the information stored somewhere so that you can easily tell whether a particular NSF has an up to date design, you can add the template version as non-editable information in the database property dialog, as shown below.


This works in Notes/Domino 6.0.1 and later, and is done by creating an editable shared field named “$TemplateBuild”. This is a special field name recognized by the database properties code; the shared field design element contains three extra items not in a normal shared field; the items are named $TemplateBuild, $TemplateBuildName and $TemplateBuildDate. You can assign values to these extra items by a LotusScript or Java agent.

The Notes/Domino 6 discussion forum contains sample LotusScript code, written by Thomas Gumz, for retrieving the version information in the $TemplateBuild element. The following code snippet is a modification to assign the values of these parameters in the template. It assumes that it is running in the same template that is to be modified; of course, you can also modify this code to operate on another database whose path is supplied as an argument the the constructor of NotesDatabase.


The following figure shows a sample output after running the above code:

1. Provide the template and the related information such as the agents that have to clean up the data, fixes, and so on to the QA Administrator.
2. The QA administrator then perform the following:
1. Copy the template on the QA server.
2. Sign the template using the server ID, their ID, or a test ID.
3. In the QA environment, enable the target database property of inheritance to inherit from the master template. Then refresh the design of this target database in the QA environment. On successful refreshing the template, the version details will appear as additional information (See the figure below). 
   
4. Notify the QA team that the application is ready for testing.

Let us review how Domino design refresh works: When you select a Domino application and select File -> Database -> Refresh Design, Domino retrieves the database's template name found on the design tab of the database properties box and then locates the template with that master template name. Domino matches up design elements between the application and the template, deciding which are to be updated, added or deleted. This matching algorithm is fairly complicated, using the universal ID of the design notes, the value in the $TITLE item (particularly the last value, the alias), the language setting if this is a multilingual application, and the Notes/web/modile setting. These last two are used in case there are design elements with the same name but different languages, or designed for different clients. Generally speaking, the details of how the match is done aren't important, but if it seems like design replace/refresh isn't working as you expected, consider the possibility that by renaming a design element, you have made the design replace process not realize that it's "the same" design element as before.

Testing the application

For testing, you must have test IDs that represent the different levels of access that user can have with the application. If you have users the are reader and others can edit, then you need test IDs with the same access level. Domino has the ability to hide and control access to everything from the application down to the individual design elements.

The application has to be tested not only for correct functionality but also using the client application that the end user will be utilizing. Different version of the Notes clients do not have as much issues as different version of browsers have. Unless this is for internal use and everyone has the same browser, you have to be able to test the application with a variety of browsers and versions. There is a few open source tools that can be used for testing web based applications. The benefit of using these are that you can test overall functionality very easily and be sure there are no regression issues. Your changes to one form may cause another form or code to now malfunction.

Testing the entire application for each release can be very time consuming. That is why it is important to document the changes made in development and build a test case for those changes. The test case will indicate what functionality the users should see. It should correspond to the original change or design request. An example is adding a new form for the user, the design requirements will list the fields and the expected workflow. The test case would be the steps the user will take to utilize the form and the expected out come.

Especially for new applications, performance testing under realistic conditions of server load and number of documents is very important. We very commonly see applications that worked fine with a few dozen test documents and one user, but once they get tens of thousands of documents, their performance suffers badly. These problems can be addressed by following the design principles in the whitepaper "Performance basics for IBM Lotus Notes developers."

QA to production

When the application has been fully tested, there should have an approval process to indicate it is ready for production deployment. Provide the template and related information such as the agents that have to clean up the data, fixes, and so on, to the production administrator. The Production administrator then do the following:

1. Sign the template using the server's ID or the administrator ID used for signing.
2. Apply the QA template to the appropriate Domino database.
3. Run any update agents that are needed.
4. Enable all scheduled agents.
5. Notify users of updates

Parent topic: 3.0 Infrastructure impact for application development