3.6 Team development considerations 

Previous | Next

While Domino provides an excellent Rapid Application Development environment that allows a single developer to create some great applications, there are projects that require a team's effort. The most challenging part of working in a team is to communicate what changes are being made so you do not delete another team member's work. As with any code development, you should have a place for the team to see who is working on which design elements and what the changes will be.

Plan your changes to group the changes together into one release. This helps make the testing easier. For each release, you have to coordinate which design changes can go forward and which have to be pushed to the next release.

Work locally

Unless you have a really fast development server, it is better to code locally. There is always a chance that someone else's code might crash the development server and you can lose your work. Replicate often so you have a backup and you get the changes from others. For testing the XPage, use the development server, it provides a better test environment then viewing locally.

Turn on design locking

Replication conflicts between design elements are generally handled be choosing one "winner" and discarding the duplicates. If the discarded design element contains three hours of another team member's work, they may not be happy about this. By enabling the design locking feature of Domino Designer, only one developer will be able to work on a given design element at any given time.

If developers are working in local replicas, this is especially important, since they normally will not get the message about save conflict unless the other developer's change has already replicated to their local replica. Design locking does work in local replicas -- the client will contact the administration server for permission to edit the design element. If the user can't reach the administration server, they do have the option to do a provisional checkout and edit the design element anyway; but make sure they know this is a Bad Idea unless they're sure nobody else is working on that design element.

Turn off automatic project build

 
By default, project building in XPages applications, is performed automatically when you save changes. If you need more control over when builds occur, you can disable automatic building function and manually invoke the build function. The automatic build is disabled sometime when the building should wait until a large set of changes is finished. The disadvantage of manual building is that tasks generated to indicate build errors quickly become out of date until you build again. In addition, it is important to remember to manually build the project before running those applications that rely on the build output, for example, before running your Java program. 

You can turn on and off this option on Workbench using the action menu Project -> Build Automatically, which is a toggle menu of on and off.  If set to on, whenever a resource is modified, another incremental build occurs.


 
Alternatively, you can follow these steps to turn on or of the Build Automatically option:

1. Open the  File -> Preference -> Workspace page. 
2. Select the Build Automatically . 
3. Click OK to close the Preferences page.

While the Build Automatically option makes the build process easy, that you do not have to remember to build to see your changes, it will build all code in the NSF, including changes others have made. As you make changes to an XPage or custom control, you can do a Build Project on each design element. Turning off the build automatically option allows you to shorten the build process and make it faster if you intend to just build the design elements you need to test. 

Use same version of Domino Designer for all team members

When you build an XPage, the build process recompiles anything that was complied with an older version or fix pack that has controls that have been updated in the newer version of Designer. This is a real problem if you have Build Automatically enabled since it will build design elements it thinks needs it. The older version XPage or Custom Control will now have your name and the current date and time assigned to the design element. It will look like that you have changed the design element while you had not actually touched it.  When you replicate back to the server, you could overwrite changes made by the developer using the older version of the Designer.

Assigned code changes

If possible, assign changes by the design elements that will be modified so you do not have two developers trying to update the same design element. The code libraries give the best chance of over ridding someone else changes. Code libraries allow you to centralize your LotusScript, Java, and JavaScript code. As part of the communications of which design elements are to be change, do not forget to include the code libraries.

Use a third party tool to control the changes

There are tools available to help with controlling the development process. These tools run from the simple code documentation through to design element check-in and out. The version 8.5.3 of Domino Designer supports using a source version control. This is discussed in 3.7 Code control.

Visit OpenNTF.org to see what open source tools are available to help you manage your development.

Parent topic: 3.0 Infrastructure impact for application development