Development Process

Development Environment

You will require:

• An ASP File Editor (Notepad++ recommended)
• Visual SourceSafe Client
• A Local MySQL Database instance, configured with the latest Vision database
• A Local IIS implementation, with a local copy of the CALIDUS Vision product.

A Notepad++ installer is available on the shared project drive in P:\271321 - Vision\_Development\Development Tools\npp.5.8.1.Installer.exe.

The Visual SourceSafe Client installer is available on the shared project drive in P:\VSS\NETSETUP.EXE

For details on installing these MySQL and IIS, please see the Initial Installation process.

Development Process

• Always change code though SourceSafe, after checking out the file first.
• Always follow the examples of existing code in the project.
• Always create generic ASP and JavaScript functions where possible. Add them to CommonASP.asp and Common.js respectively.

Committing Changes

When checking code back in, check the changes you have made using SourceSafe’s Show Differences function. Ensure that all changes are detailed when checking back in. The format for these comments should be:

{supimix ref}/{client ref} for {client}/{Area}/{site} – {Description}

If there are multiple changes made for this log, separate them with semi-colons.

If there are multiple logs, add the changes made for each log subsequently, in the same format.

Example:

272693/SW-7YYJEU for DHL/EMEA/CHEW - Added choice of employee; 
Added extended Export functionality (through to HTML-style XLS sheet).
272694/SW-7YYJNV for DHL/EMEA/CHEW - Fixed bug created during testing 
regarding setting the user default values for the Productivity Settings selection.

Ensure where possible that the descriptions are relevant to the users, as these will form the release notes later.

Changing the Database

All changes should be made to the local development database.

When changes are complete, the SQL changes should be copied into the file

P:\271321 - Vision\_Installers\Releases In Progress\LatestDBChanges.SQL

All table changes should preserve data, so tables should never be dropped, simply altered.

Remove any reference to the schema from the code – the schema (generically Productivity1) is identified at the top of the script. If this is ever changed (or multiple schemas are used for development and release), it will be easier to change if this is only at the top of the script once. If objects are being added to other schemata, either explicitly add the schema on the SQL by exception or create a new copy of the script for changes solely for that schema.