Get the most from Notes®

Check In – Check Out:

As I stated, the file locking system (known as ‘check in and check out’) is usually the first thing that comes to mind when discussing version control. This is an important feature as it allows developers to work on design elements without fear of others working on those same elements concurrently and overwriting any changes. This is especially important for dispersed teams who do not know what elements other developers are working on at any given time.

Having all your design elements and DBs in one central repository allows the management of development to be more comprehensive. Developers or managers are aware of any changes made to local copies of design elements. These will need to be added to the server copy later if someone else has checked out the element first to make other changes.

Versioning and Rollback:

With version control you have a central repository to store versions of design elements. Changes are checked in to the VCS and if any issues arise, such as a recent change in one element affecting other design elements in a form, the offending design element can be rolled back to a stable version. However the new version of the element is not discarded but stored as a version itself so changes can be made safely to correct any issues. Source code between versions can be compared side by side to easily spot code differences that may be causing issues. Any changes to fix the issues can be re-released as another version of the design element.

On a larger scale this is also applied to databases. Current environments I’ve seen have multiple copies of DBs on local developers’ workstations and on a development server. This can quickly grow into an unmanaged situation where no one knows what functionality is included in which version or even where a specific version is.

Obviously for larger teams, especially dispersed teams, ensuring that nobody is making changes to a local copy that needs to be committed before a DB is copied to a production environment is another activity a team lead or manager needs to ensure has been completed before the DB is moved.

“Which version do we need to update the production server with?”

Branching and Merging:

Branching allows you to create a copy of your application. The VCS is capable of managing multiple, concurrent versions of your application. Developers can work on separate versions at the same time. This is useful anytime changes are being implemented but are not ready for the next release, or will not be included in a specific version. For example, changes made for v2.0 of your application will never be included in v1.5. However v2.0 might not be ready for 3 months while releases of v1.5 (v1.5.1, v1.5.2, etc.) are scheduled every 2 weeks.

This is also useful for developers who need to work on the same DB concurrently and cannot wait for their peers to release control (check code in to the VCS) of certain design elements.

Merging is the process of keeping common functionality and bug fixes in sync between separate branches. A merge must occur if 2 or more developers are working on the same DB concurrently for different reasons and their changes have to be incorporated into a single code base without overwriting each others work. VCS have features to manage this process in a more controlled manner than attempting to manage this manually.

Issue Tracking and Audit Trail:

When changes are made to design elements, the VCS can be configured to enforce (mandatory or optional) comments to be added to any changes made. These comments give reasons for the changes and can be accessed for reporting or investigation purposes later.

Some VCSs have the functionality of linking any changes to feature request/bug tracking systems. Any changes that are made can be directly linked to tickets providing additional details about the change.

And yes, because all changes are tracked by date and individual, audit history is preserved for governance or compliance

Version Control for Notes

In all Java projects I’ve worked on over the last seven or eight years, implementing a VCS on day one of the project was standard practice. Prior to this, I recall the pain of losing work when the Microsoft ‘Blue Screen of Death’ suddenly appeared, the IDE crashed and I realized I was working on the wrong version of an application!!!

For many languages this process has been aided with the choice of at least a dozen different offerings from vendors or from the free Open Source market. However, an issue for a Lotus Notes VCS strategy is that a file based versioning structure cannot work effectively with Notes databases as the Notes Database is it’s own entity that is difficult to store in this format. As an aside, Teamstudio have created CIAO!, a unique VCS specifically designed to handle Notes databases, templates and design elements.

I suppose the acid test in deciding whether you use a VCS or not is: ‘Are you willing to lose what you have?’