Configuration Management applied to Uniface

Since Uniface was first publicly released, developers have loved and loathed the fact that their source code has been stored in the database. Now Uniface developers can have the best of both worlds, CM using standard tools, and the source code stored in a structured fashion.

Before we look at how to use Uniface with source code control, there are some ground level decisions that need to be made. We call it 'A methodology for Uniface source code control'.

Uniface without controls

When Uniface is used without an external source code manager, all your source code is stored in the one place, in a database of your choosing. Whether it is code that is 'in progress' or 'being fixed' or code that is not being modified at all.

You may set up several databases, and copy code between them, using TRX import/export, however each database contains ALL of your source code.

Uniface requires this since it stores your source code in database tables. For example: A single table may contain 2 'components', one a hidden form or service, and another a display form. The display form is being fixed, but the hidden form is 'reference code' that the developer should not change. However since they are in the same database table, if the developer has access rights to modify one record, he/she can modify any.

This is usually controlled by only exporting/importing the components that SHOULD HAVE changed. This however often leads to errors in the test or QA environments, or worse, when the other program is SUPPOSED to be changed, later on, miscellaneous uncontrolled changes leaking in from the earlier developers efforts.

Uniface with UD6/CMtool driver and a SCM/CM tool

The UD6/CMtool driver prevents these code control issues by storing EACH COMPONENT in its own file that may be controlled by a SCM/CM tool or operating system permission system.

However this now means that you have some choices to make, that you never had before. The most basic is, this:

• Where do I store my 'reference code'?
• Where do I store my 'developer code' (sandbox)?

Furthermore, the second question, 'where do I store my developer code' breaks down into:

• Do ALL developers have access to ALL 'checked out' code?
• Do only developers in the same WORKGROUP have access to the same 'checked out' code?
• Does EACH developer only have access to their 'checked out' code?

Various combinations of these 3 techniques can be used, but it is important to understand how.

The source code that developers CANNOT change

UD6/CMtool driver stores your Uniface source code in plain ASCII text files (in XML format), in a directory tree as defined by your assignment file and the joins file (see the Guide to Installing UD6/CMtool driver for more information on these files).

Once your source code is loaded into this 'tree', and compiled, the first step of implementing change control is usually to make this 'read-only', either by setting operating system permissions, or loading it into a source code control repository or a combination of both.

Some SCM tools ONLY store your source code into a repository and provide no way of providing a read-only view. For these tools (like CVS and PVCS), a 'script' must be ran each time an object is checked in or checked out, to maintain a 'reference area'. March Hare provides details of how to set these scripts up in the relevant sections of this help file.

Other CM tools like ClearCase provide their own NFS-like file systems for providing read-only access.

The source code that one or more developers CAN change

Configuration control is more than simply making a file read only or read-write. A change should not be committed to the 'reference area' until it is complete. In that way, some users of the source code can see the 'work in progress' whilst other users can still see the 'authorised' version.

Therefore, when a developer wishes to modify code it is 'copied' to another place. This is called the INUSE area, sandbox, developers area, working directory etc. The UD6/CMtool driver differentiates these files from the main stream of code, by listing them in the INUSE file. The INUSE file is maintained by the auxiliary programs add2list.exe and del2list.exe.

March Hare provide details of how to automate the calling of these programs during check-in and check-out operations for most popular SCM/CM tools. Please see the relevant sections of this help file for specific instructions.

If you wish for several or all developers to be able to see code that is being modified:.

• The INUSE file will need to be located in a centrally shared place, like on a SAMBA share or NT share. You can set the location of this file using the INUSE parameter in USYS$UD6_PARAMS .
• The 'checked-out' source code will need to be located in a centrally shared place, like on a SAMBA share or NT share.

Protecting the source from tampering

Some people wish to go a step further, and prevent the developers having direct access through the operating system to source code that they should not able modify. The March Hare UD6/CMtool Driver supports this through the use of Polyserver.

In this situation, the files exist on server(s) and can be 'seen' by the machine running the polyserver. The INUSE file, JOINS file etc. all exist on the polyserver host. Different developers, or development teams, can have their own INUSE and JOINS files through the use of different logins (set in the client assignment file).

The developer cannot 'see' the source code except through the IDF. In the IDF the developer can only see and access the source code that the SCM/CM tool and the UD6/CMtool driver configuration files are set up to allow them.

Setting the UD6/CMtool Driver up in this way is straightforward for an administrator with suitable Polyserver training. If you do not have such a person available, March Hare can assist with trained consultants.

A word of advice

March Hare have found that if an organisation that develops with Uniface wants to use more of the features of source code control, like developer workgroups etc., that to achieve success they need to:

• Invest in developers becoming familiar with the Source Code Manager/Configuration Management tool being used (i.e.: ClearCase, PVCS etc.).
• Use a methodology that allows developers to control how they access the source code (like UD6/CMtool Driver).

We have seen an especially high rate of failure when the developers are 'protected' from the underlying source code manager/configuration manager. The organisations that have built and sell tools like PVCS, eChange Man and ClearCase have invested considerable time and money into developing products that assist developers.

Hiding these from the developers seems to create a high level of failure.