Series: Adapting Oracle Application Development Framework and Subversion to Your Enterprise’s Needs 


Part 3: Migrating Your Oracle ADF Application to Test and Making Fixes

by Chris Muir

This is Part 3 of a five-part series on adapting Oracle ADF development and Subversion to your enterprise’s needs. It covers:

  • The first migration of an application to Test

  • Testing and changes that result in merges back to Development

First Migration to Test

At some point in time, the Development code base within the Beanz\trunk is considered ready to move to the Test environment. Normally, this would occur because the developers think they've met the requirements of the Change Request or because enough functionality is available to allow testers to start testing the subsystem.

It is assumed all developers have ceased coding at this point and all their changes have been committed to the Beanz\trunk (namely the HEAD revision). It is important at this stage that developers understand all requirements must have been met and no new changes can be snuck in to the code. As such, a psychological “freeze” on development might be enforced on the team's development.

The lead developer creates a Change Request tag (for example, CR001) based on the Beanz\trunk Development tree directly against the repository, not affecting any developer’s working copy. The tag is applied at the application level within Oracle JDeveloper. To do this, the lead developer right-click's the trunk branch under the Versioning Navigator and selects the Branch/Tag option. This opens the Branch/Tag dialog:

adfsvn3-1

Here, we can see where the code will be copied from, based on the latest HEAD revision. In turn, in the To field, we can define that the complete code base is copied into a newly created repository directory, tags/CR001. The result can be seen in the Versioning Navigator:

adfsvn3-2

Tip:


Note that not all files need be tagged, because not all files are necessarily candidates to move to Test. Alternatively, individual files or projects can be tagged, though this comes with the tradeoffs of the extra work involved and the risk that you may not move dependent files, which could lead to more work in the long term.
 

Development teams should not be afraid of tagging or branching in SVN due to concerns about the amount of disk space used. SVN uses a sophisticated internal mechanism that keeps only one copy of each file version, regardless of how many tags or branches are created. In fact, even between versions of a specific file, SVN doesn’t keep an entire copy of the changes file, but rather it keeps just the “delta” changes since the previous version.


At this point, we now have a complete snapshot through the tag mechanism providing a permanent record of the code destined for Test. We now migrate the application to Test by creating a branch. As policy, always use a tag as the source of the branch creation. The lead developer creates an SVN branch via the Oracle JDeveloper Versioning Navigator window at Beanz\tags\CR001 to Beanz\branches\test using the same Branch/Tag option in the Versioning Navigator:

adfsvn3-3

This is the resulting view in the Versioning Navigator:

adfsvn3-4

The lead developer then updates the change request documentation to state that the code to be deployed to the Test environment has been tagged as CR001, the code exists under the Beanz\branches\test SVN directory, and the CR is reassigned to the change-control team.

Your change control system now looks like this:

CR#

App

Description

Status

Assigned

CR001

Beanz

Build new Beanz system

Test

Change control

Task

Please migrate application to Test environment.

 

The change-control officer will check out the complete Beanz\branches\test code as a working copy through Oracle JDeveloper and create an EAR file using the Test deployment descriptor.

The EAR file is attached to the change request as a copy of what will be deployed to the Test Oracle WebLogic Server, and a copy of the EAR file is sent to the Test Oracle WebLogic Server administrator. The CR is then assigned to the Test Oracle WebLogic Server administrator. Your change control system now looks like this:

CR#

App

Description

Status

Assigned

CR001

Beanz

Build new Beanz system

Test

Test Oracle WebLogic Server Admin

Task

Please migrate EAR file to Test Oracle WebLogic Server

 

The Test Oracle WebLogic Server administrator deploys the EAR file to the Test Oracle WebLogic Server and configures the server and application appropriately (a separate discussion that is beyond the scope of this document).

The Test Oracle WebLogic Server administrator then marks the work as complete, assigning the CR back to the change-control officer. The change-control officer then assigns the CR back to the testers as ready for testing. Your change control system now looks like this:

CR#

App

Description

Status

Assigned

CR001

Beanz

Build new Beanz system

Test

Testers

Task

Please test application deployed to Test Oracle WebLogic Server

 

Testing and Changes that Result in Merges back to Development

At this point in time, developers are likely to continue development on Beanz\trunk, while testers are testing the application deployed to the Test Oracle WebLogic Server.

Potentially, errors will be found in the Test application or changes will be required by the testers. The CR will be reassigned to a developer to make the appropriate changes. Your change control system now looks like this:

CR#

App

Description

Status

Assigned

CR001

Beanz

Build new Beanz system

Test

Developers

Task

Problem found in Test Oracle WebLogic Server application; please fix.

 

In order to replicate the issues seen in the Test environment, the developer can either check out a working copy of the CR001 tag code or check out a working copy of the branches\test code. It doesn't matter which is done in this case, because if the described processes have been followed, both the CR001 tag and branches\test code will be the same code base. For the following discussion, we'll assume the developer checks out a working copy from the Test branch.

Ideally, the developer should identify the problem and the offending code, change the source code to create a fix or change, and commit the changes back to the Test branch, where the testers can continue to test with the new applied fix.

Upon committing the changes, the developer flags the change-control officer that the officer needs to build another EAR file from the Test branch and give this to the Test Oracle WebLogic Server administrator to deploy and configure (as described in the last section). Your change control system initially looks like this as the developer passes control back to the change-control officer.

CR#

App

Description

Status

Assigned

CR001

Beanz

Build new Beanz system

Test

Change-control officer

Task

Problems found and fixed. Checked back into CR001. Please migrate fresh app to Test environment.


The change-control officer will then checks out CR001, creates another EAR file, uploads to the CR, and reassigns to the Test Oracle WebLogic Server administrator to deploy to the Test Oracle WebLogic Server. Your change control system now looks like this:

CR#

App

Description

Status

Assigned

CR001

Beanz

Build new Beanz system

Test

Test Oracle WebLogic Server Admin

Task

Please migrate EAR file to Test Oracle WebLogic Server.


The Test Oracle WebLogic Server administrator then marks the work as complete, assigning control back to the change-control officer. The change-control officer then assigns the CR back to the testers for testing. Your change control system now looks like this:

CR#

App

Description

Status

Assigned

CR001

Beanz

Build new Beanz system

Test

Testers

Task

Please test application deployed to Test Oracle WebLogic Server.


It is worth noting that while changes have occurred in the Test branch, changes may also be proceeding in the trunk as other development continues:

adfsvn3-5-small  

[Click here to see a larger version]

At this stage, the fixes created for the Test branch need to be applied back to the trunk and the CR001 tag. We need to apply them to the trunk so that all future development includes the fixes. In addition, because the CR001 tag represents this particular release, it also needs a copy of the fixes. Later, as additional tags are migrated to the Test branch, any fixes to the Test branch need to be applied only against the current tag applied to the Test branch, not to earlier tags such as CR001.

The act of applying the Test branch against the trunk and the CR001 tag is a branch merge. A branch merge is done by checking out a working copy of the lesser branch (that is, the trunk or CR001 tag that are missing the required changes) and then merging in the greater branch.

In the following example, a working copy of the trunk is merged with the contents of the Test branch. The developer’s Application Navigator containing the trunk’s working copy appears as follows:

adfsvn3-6

The assumption here is that the developer has the latest working copy of the trunk from the repository. If not, the developer must update the working copy using the Applications menu’s dropdown picklist → Versioning → Update Working Copy option:

adfsvn3-7

Updating the working copy results in the following SVN log entry:

adfsvn3-8

With the trunk working copy, we then attempt the branch merge using the Applications Menu’s dropdown picklist → Versioning → Merge Working Copy option. This invokes the Subversion Merge Wizard where we choose to reintegrate a branch with the current trunk working copy:

adfsvn3-9

Tip:


For an explanation of each of these options consult Susan Duncan's blog post Making Merge, Revert and Branching Easier with SVN.


Step 2 defines which branch we’ll merge from and the working copy we’ll merge to:

adfsvn3-10

Step 3 allows us to test the merge before it is finalized. In this case, we see an irresolvable merge (that is, a conflict where Subversion can’t undertake the merge automatically for us) occurred:

adfsvn3-11

Upon completing the Merge Wizard, we see the same output in the log window:

adfsvn3-12

The Application Navigator is flagging a conflict on the SearchBeanz.jspx file with a conflict icon:

adfsvn3-13

And so, too, the conflict is flagged in the Pending Changes window:

adfsvn3-14

Right-clicking this file and selecting Resolve Conflicts presents the Oracle JDeveloper three-pane merge facility:

adfsvn3-15

Here, the developer must manually resolve the conflict. The particular code example is a trivial one for the purpose of this article.

Tip:


Oracle ACE Director John Stegeman provides the "ADF Essentials" on working with Subversion includes an excellent description of Resolving Conflicts using Subversion to merge two developers' code changes.


Once the merge is resolved, the log window shows the resolution:

adfsvn3-16

The Pending Changes window flags the updated file with the merged changes, ready to be committed to the repository:

adfsvn3-17

And after committing the working copy, the new revision resulting from the conflict resolution can be seen in the Application Navigator:

adfsvn3-18

The same revision is reflected in the Subversion repository:

adfsvn3-19

The Version Tree tool (opened by right clicking the file at hand, then selecting Versioning followed by Version Tree) helps us understand what we've just done. We can see that from the test branch revision 12 where the fix was made, it was merged back into the main trunk to create revision 13.

adfsvn3-20

Finally, the same process must be repeated for the tags\CR001, where a working copy of the CR001 tag is checked out, then merged with the test branch.

Summary

In this installment we have investigated the change control scenarios of migrating our application to test for the first time, as well as testing our application and migrating any fixes back to the main Subversion development trunk. In the next chapter we will investigate the first migration of the application production, and then consider further CRs moved through the whole development, test and production environments.

Go to Part 4 | Back to Series TOC



Chris Muir
, an Oracle ACE Director, is a senior Oracle systems developer and trainer for SAGE Computing Services in Australia. In 2009, Chris was awarded the coveted Oracle ACE Director of the Year prize from Oracle Magazine. In addition to nearly 10 years experience working in traditional Oracle development environments, he has more recently earned battle scars working with training and promoting Oracle JDeveloper and Oracle ADF. He is a frequent presenter at user group events, and more recently he can be found hanging out in the ADF Enterprise Methodology Group’s forums, where Oracle ADF advocates talk about some of the big-league challenges of Oracle ADF development.