Tuesday, 21 September 2010

OI Source Code Management in 9.2.1



Slightly later than I’d hoped and indicated in earlier blog postings, but this one WILL be worth the wait for all of you cutting and maintaining OpenInsight code.

One of the major highlights in the next version of OpenInsight will be Version Control, something that I find very exciting, not because I’m a programmer who will use it (I’m not), but because so many of you have asked for this at recent RUGs and road shows around the world. Furthermore, I only saw an early ‘in-development’ preview, but it is clear that Revelation have again listened, researched and are building into the tool the best practice from a whole bunch of products – this is one that you guys are going to love.

So what does it contain at the present time?

Well, the Environment Settings in OpenInsight 9.2.1 include a new switch where the source control can be turned on or off for your system. This provides you with a nice and easy single turn on, as needed. Then the SCM (Source Code Management) option from the SCM menu item in the System Editor ++, provides access to all of the SCM tools.

The first menu item that Mike took me through was the SCM Panel option. This launches a window that provides you with a pick list of your programs (Stored Procedures) and below that the change information for the chosen program. This change information currently includes the date and time, the version and who the program was changed by. If you then select a version, you will be presented with the actual program code towards the bottom half of the window – this displays the program code as it was at that point in time.

However, this window does a whole lot more. There is a facility to delete individual versions (version records that are displayed in the table), or you can select multiple rows and block delete version records. There will also be a facility to select all versions before a certain date and delete all of those. This will help to keep the system refined and clutter free.

If you select two programs, the compare button becomes enabled and the power of this tool really comes into play. You will be presented with two copies of the program side by side, one version to the left and one to the right. Then, the system will colour the code based on the differences between the two versions of code. The colouring is based on ‘what is in the new version and not in the old version’ and ‘what is in the old version and not in the new version’. The system also drops in spacing lines to line up the code and this makes working with the two side by side super simple. As you would expect, these colours for the changes can be changed to suit your own personal preference.

Once you have decided which version you should be using in your application, you simply have to click one button ‘Make Live’ and OpenInsight will use that version.

The SCM menu item also includes a ‘Versioning’ menu item. This module enables developers to select stored procedures in several ways (for example, all entities that have been changed since a specific date and time) and then assign version numbers to those programs. These version numbers are then reproduced on the SCM panel window alongside the program.

If that was not enough, Revelation has also included the ability to create and maintain modules. Choosing ‘Modules’ from the SCM menu in the system Editor ++ will display a window showing all of the modules that you have defined in your system. Modules, are packages of programs and executables that make up a part of your application. For example, I have an email system in my new OI based contact manager. I could create a module called ‘Email System’ and assign all of my programs and executables used to drive that part of my application to that module. It is also possible to assign one program to multiple modules. When you assign source code to a module, OpenInsight will automatically pick up and assign the object code to the module to make deployment super easy.

So, once we have the modules set up and populated with our programs, we can turn to the Deployment Kit (Deploy application button in the Application Manager), create a new Repository View, grab our chosen module and you’ll get all of the procedures and executables that they module needs ready for deployment. Many people ask me how they can easily identify what they need to deploy in upgrades as they deploy upgrades but sometimes miss important entities. Well now, you can create and maintain your modules and never have to worry about missing entities again – assuming you remember to assign new entities that you create to the correct module ;).

I liked what Mike had to show me about the System Editor ++ and QBF enhancements, but this one really blew me away. I’ll be creating some videos on these new features when I have access to the Alpha or Beta. In the meantime, I’ll leave the guys at Revelation to continue finishing these great additions to the forthcoming OpenInsight 9.2.1.

2 comments:

  1. "Version control is a fantastic addition to OpenInsight. I'm looking forward to the release of 9.2.1 "

    David G

    ReplyDelete
  2. This goes part way to solving the problem but only covers stored procedures.

    The modules idea is the right way to go. Our development control system uses 'modules' to check entities into and out of. What ours also does is allow checkout to a module of all entities - data, dictionaries, windows, events, inserts etc.

    We have allowed for events being created after a window has been checked-out by adding an 'update module' feature. This scans the repository for the selected window and adds to the module any events for that window. The update had to be 'smart' enough to clear out child entities before adding child entities of windows (as some may have been removed).

    The one short coming (we have yet to resolve) is the going back to a previous version of a window. We need to reinstate the correct events for the restored version of a window.

    Not only does all of the above build our RDK 'modules' as we are creating or modifying any entities, but each entity as it is added to a 'module' is checked out to the owner of that module. This prevents other developers from working on the same entities.

    We have a junior programmer, who is assigned work which is not entered into any module. When he has finished his task we can then add the finished entity to 'our' module.

    It's not perfect but to does help a lot!

    ReplyDelete