January 2006 Volume 10, Number 1

Manage Multiple Versions of Your Software with TurnOver

By Joe Baumgarten, Sales Engineer

By the time you read this article, the holidays will be over, and you probably have had your fill of turkey and tinsel. Perhaps you have also had your fill of at least one relative? Without a doubt, relatives can sometimes be difficult to manage. However, now that you have survived yet another holiday season and are back to the relative peace and quiet of your office, let’s talk turkey on how TurnOver manages relatives. And, I promise, that will be the last pun.

TurnOver has been helping advanced IT software shops manage multiple versions of their software since, well, the second release of TurnOver. Think about it! Our developers here at SoftLanding use TurnOver every day to manage TurnOver. Once development on Release 2 began, they realized that they were going to need some help managing two different versions of just about every object that made up the application. To that end, they created the concept in TurnOver known as related applications.

Fast forward now about, oh, seventeen years, to a more recent past. Suddenly TurnOver is managing not only iSeries native code, but code with extensions such as .java, .html, .gif, .exe, and so forth. How can we wrap our arms around that unique style of development, but stay within our core Change Management “best practices” benefits? At this point, we introduced an advanced PC version control module called TurnOverSVN. And, lo and behold, the PC developers using this module needed to manage multiple versions of their software as much (if not more) than their iSeries counterparts. Later I’ll introduce you to the TurnOverSVN concepts of branch, tag, and merge.

iSeries Related Applications

As you know, TurnOver drops over the top of your application’s library structure with an application definition. This application has one or many levels, which denote the specific target of a promotion. For example, see the Release One application definition pictured in Figure 1. You can see that Level One is the quality assurance library, QALIB1, and that Level Two is the live production library, PRODLIB1. When Release Two begins, we’ll create a similar application definition over a similar library structure: QALIB2 to PRODLIB2. However, notice that we’ve made the original version of the code in PRODLIB1 available to the Release Two developers by adding it to the Release Two application definition as a locked level called Level 3. A locked level tells TurnOver that source code in this level’s libraries can be checked out for subsequent modification, but no modified source code can be promoted back into this level. The highest that change can move in the Release Two application is to Level Two: PRODLIB2.

In this scenario, a developer who needs to make a change to PGMA needs to understand which of the two programs needs to be changed: is it the version in Release One or the version in Release Two? What if the change needs to be made to both versions? Does the developer even realize that there are two versions? This is where the true power of TurnOver’s related applications comes into play.

Once the two application definitions are in place, the next step is for TurnOver to relate the applications to each other. We will designate Release One as the parent application and Release Two as the child application, and voila! they are related. It really is as simple as that. But, surely, anything so simple to construct can’t have that much value, can it?

The first place where a developer will find value is in the analysis mode. When Joe places PGMA on his worklist against the parent application, he can proactively check for any related version of this program in the child application (Release Two) by using Option 16: Check Related Objects from this worklist.¹ If TurnOver finds any related objects, it shows these on the Work with Related Applications panel. From that panel, he can perform further analysis on the related object(s) shown, and add them to the worklist if he decides a change needs to be made there as well. Also, remember that TurnOver includes a very powerful source code compare command: CMPSRCMBR. You can use this command “ad hoc” any time you want. However, it is also the main driving engine behind Synchronizer’s Impact Analysis tool (see Synchronizer article in this issue).

Figure 1: Original code in PRODLIB1 is a locked level
in the Release Two application definition.

If Joe forgets to be proactive, then TurnOver becomes reactive! When Joe checks out the source code for PGMA of Release One, TurnOver checks if a version of this same object exists in the child application. If so, it completes the original checkout but flags the original object as one in Conflict. At this point, Joe can use Option 26: Conflicts² to get the information he needs to resolve the conflict. He can certainly add it to his worklist and check it out, or he can resolve it with a reason code, such as “do later” or “obsolete.”

If, despite all of TurnOver’s friendly options and polite “excuse me’s,” Joe persists on promoting PGMA of Release One without resolving the conflict, TurnOver uses its last resort: it will not let forms run at any level that contain objects with unresolved conflicts. This brings us to the final method where TurnOver provides some assistance: form promotion time. In Joe’s case above, he now has two versions of the same program on the same worklist, each one traveling through its respective libraries according to its associated application definition. When promotion time rolls around, TurnOver will generate two forms, one for each application. TurnOver sees the two forms and will prompt you to group them together. Thus, if one fails, the other is recovered as well. This is especially handy for complex promotions where physical files, copy books, and so forth are promoted in one form, and programs dependent upon them are promoted in the second.

SVN Branch, Tag, and Merge

Well, if you thought managing your own relatives was difficult, how in the world do you think you are going to manage the relatives of your significant other? For those of you who, like me, grew up in the relative simplicity of iSeries programming, trying to get your head around the ins and outs of coding Java, Visual Basic, and .NET seems insurmountable. Of course, it’s not. You just look for the similarities to what you already know and build from there. It is no different when you learn PC source version control. Some things are comfortably similar; some are radically different.

Let’s start with a similarity. TurnOverSVN manages access to a repository, a directory structure of your master artifacts. This is similar in concept to how TurnOver manages access to your native iSeries source code that is contained in production source files. The only way that developers should be able to make changes to this master repository is through a controlled and managed interface.

One of the first differences that you’ll find with TurnOverSVN is that there is no per-artifact checkout that gets performed at the beginning of each task. Each developer maintains a complete copy of the entire application’s artifacts in his or her personal library. To the dyed-in-the-wool iSeries developer, this sounds like complete and utter chaos! That could possibly represent dozens, even hundreds, of “versions” of any one artifact. If Joe is going to return his source to the repository (i.e., commit), how can he be sure that his version is not wiping out code that Sally had previously written and already committed?

TurnOverSVN’s powerful merge tool is the perfect answer here. It will automatically flag as a conflict any changes that Joe and Sally made to the same line of code. That’s right, the same line of code. This is the true power of the merge tool, and why it is so immensely popular among PC developers. As long as Joe and Sally did not change the same line of code, the merge tool happily joins them together with no human intervention. Of course, if Joe is smart, he’ll update his personal copy with the latest code from the repository before he gets started, even further reducing his chances for conflicts. This type of programming is called Copy-Modify-Merge as opposed to native TurnOver’s Lock-Modify-Release. It supplies the perfect model for teams of PC developers.

Speaking of teams of PC developers, what if those developers need to work on multiple releases of their application? As if dealing with your sister-in-law wasn’t enough, now you also have to deal with her kids! In the iSeries world, we managed multiple releases with related applications. In the TurnOverSVN world, we use trunks, branches, and tags.

A trunk, as the visual implies, represents the base, the mainline code, the parent version. If developers are embarking on a lengthy project, or one that involves many artifacts, they may choose to perform their work in the secluded world of a branch. This is similar in concept to an iSeries developer checking out a copy of the master source down to his or her personal development library. During the ensuing days, all commits performed by the developer return to the branch, not to the trunk. At the end of the project, all changes from the branch are folded back into the parent versions in the trunk. The powerful merge tool pinpoints any conflicts with any trunk-based development activity that was made while the code was “off line” in the branch.

Figure 2: Copy-Modify-Merge Programming

Think of a tag as a locked level of an iSeries application. When you tag a repository, you are freezing that level of code, effectively telling all other developers to no longer change this version. This is often done at the end of one release and at the beginning of the next release.

When the final commit of the artifact is executed, the developer writes some comments about the work done and associates this commit with a TurnOver task. This logs a wealth of information into TurnOver’s central database and associates each artifact committed with the TurnOver task. Not only does this provide valuable documentation for the other members of the team, it provides the data that drives many of TurnOver’s new reports, some of which are necessary to comply with industry regulations such as Sarbanes-Oxley.

If only managing your relatives could be so easy!

¹ Or by right clicking on the item on the WDSC worklist and selecting Tools > Check Related Applications.

² If you check out the item in WDSC and it is in conflict, an error message appears in the TurnOver Console. If you double-click on this error message, a Resolve Checkout Conflict wizard appears. From here, you can either check out the item from the related application or specify the conflict resolution code.

Back to Table of Contents

WHAT'S NEW