Number: TB0010

Availability: As of BuildPro 8.00, all users.

Introduction

With the many runtime and development configurations available, it can be quite complicated to design a complete development network for developing, testing, maintaining, and running applications. This guide will highlight some possible configurations. Your ideal configuration will depend on your local requirements.
 

The Basics

First you need to be familiar with some basic concepts of a BuildPro environment:

Application Repository. The Application Repository contains all the application code or "source code". It is an internal database storing all the application objects like field definitions, screens, pulldown menus, logic code etc. BuildPro executables "run" the application from the repository. On your file system the repository is contained in various files in the "sfiles" directory. It is common that seasoned developers refer to the repository as the "sfiles". A command line program named "archive" is used to extract or import application definitions in or out of the repository.

• Application Archive. When moving applications between different systems an application archive is created containing all the application objects. As the repository could contain many different applications it is common to store revisions or copies of applications by creating an application archive. The command line utility "archive" is used to extract and import applications. On your file system an application archive is typically a file with the extension ".tdy".
   
• Visual Development Environment. The BuildPro development environment allows a developer to create and change application objects stored in the Application Repository. A multi-user development environment is created by sharing the Application Repository across a network. The development environment is a BuildPro application itself called "vision".

  In addition you may want to read BuildPro Configurations for a better understanding of the various stand-alone and networked configuration supported in BuildPro.
   

• Developing Applications. Development is always performed on the Windows PC. While the application may reside on the local PC or accessible remotely on a network, the BuildPro executable (wintdyx.exe) is run on the Windows PC while developing applications. It is not possible to run the development environment (the vision application) in thin client mode.

Distributing the Application Repository

Multiple users can develop against the same application by sharing the repository across a network. Technically this is done by "sharing" the sfiles directory across a network. Following are three configurations which demonstrate how to configure a multi-user development environment. These are ideal situations, a real world configuration would involve a combination of the below.

Option 1. Stand Alone.

The simplest configuration is to not network the repository at all. Each developer installs a full BuildPro development system on each PC. Any existing applications are archived into each developers repository. At this point each developer has a full copy of each of the applications.

Developers then decide on their specific tasks and what portions of the applications they will develop. As they complete their tasks each developer will do a selective archive of the specific new or modified objects and submit them to a central repository. This would be very similar to a check-in / check-out solution as used in traditional programming environments. See the Object Export List feature in the Tools pulldown to determine objects modified since a certain date.

The benefits of this solution is that is easy to setup, each developer can work on their own, in their own location, and have better control of the application. It is ideal for remote development. smaller applications or large solutions which are split into many different applications (essentially each developer develops and maintains their own application).

Examine the archive command to understand how to do selective archives, extract version only details, and merging of versions. Use networking technology like e-mail, ftp or shared directories to send archive files around. Keep in mind that application archives are binary files and can be compressed significantly.

If the target runtime environment is UNIX, create a series of ftp and Linux scripts to automatically transfer and load application changes (archive, transfer, un-archive) on the Linux repository. Setup properly, it shouldn't take more than 60 seconds to upload changes for testing on the destination platform, even if the destination repository is at a remote location.

Option 2. Shared under Windows.

If many developers are actively working on the same application you will need to create a shared repository. Follow a few simple steps to do this:

1. Install a full development system on a stand-alone Windows PC.
    
2. Create a shared file system on a file server (Windows). If you have several repositories, make a shared area for each repository (live, testing, prototype etc).
    
3. Copy the contents of the "sfiles" directory of the stand-alone PC to the shared area.
    
4. For each development PC, modify "RepositoryPath" in the wintoday.ini file in the "bin" directory. "RepositoryPath" should point to the shared file system (e.g. "E:\" or "E:\version2\rev1\test").

Windows Server/XP/VISTA is a good platform to act as the Repository server as it provides fast file access. As all developers share this server, it should be as fast as possible.

Option 3. Shared under Linux.

Most BuildPro applications end up running in thin client mode on Linux servers. Therefore it is important that as applications are developed they are tested in an environment as close to the target environment as possible. Setting up a shared repository on Linux will allow you to develop and run applications on the same repository.

Follow a few simple steps to do this:

1. Install a full development system on a stand-alone Windows PC.
2. Install a full development system on the Linux server.
3. Create a shared file system on the Linux server.
4. Copy the contents of the "sfiles" directory of the Linux server to the shared area.
5. On the Linux server, modify "RepositoryPath" in the .todayrc in the "bin" directory. The "RepositoryPath" should point to the shared area.
6. For each development PC, modify "RepositoryPath" in the wintoday.ini file in the "bin" directory. "RepositoryPath" should point to the shared file system (e.g. "E:\" or "E:\version2\rev1\testing").
7. Create short-cuts to run the application in thin-client mode. In this case never run the application from the BuildPro developer. Only run the application from the client. This will allow you to use the database interfaces of the Linux system to access data while testing.

Use utilities like SAMBA or NFS to create shared file systems under Linux. Performance is very important so make sure the Linux system is properly configured and that the shared file systems are cached on the Windows PCs.

Note: We have noticed the many NFS solutions do not handle record level locking for remotely accessed files. Incorrect locking will generate TIP errors (potentially sfile corruptions) while developing applications. We suggest a SMB compliant sharing mechanism instead (such as Lan Manager, SAMBA etc).

The Development Server

In all the above options it is good to designate a single machine as the development server. In options 2 and 3, this would ideally be the Windows or Linux server hosting the Repository. There are several tasks appropriate for the Development Server:

• Hosting of the main repositories and application archives. Besides acting as a central storage place for your source code, this is a good place from which to perform backups.
   
• Run automated procedures. Periodic procedures should be put in place to care for your Repositories. This would include nightly archiving of applications into archive files and weekly consistency checking of the Repository database (see remake, reorder, namelist utilities).
   
• The fastest generate will always be performed by the server hosting the Repositories. While each individual developer will generate their own specific changes, a "Generate All" should be performed periodically. Create scripts to perform generates either periodically or on demand.