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

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

by Chris Muir

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

• Our application’s first migration to Production

• Further CRs moved from Development to Test to Production

First Migration to Production

At some point in time, the Test branch will be considered ready to move to the Production environment, usually when testing has been completed and the quality assurance team is happy with the software solution.

Similar to the first migration to Test, if any developers are working on the Test branch, they check in all their changes and then freeze development on the Test branch. Potentially, the program originally migrated to Test might have had no development on it (because it's perfect!), so a developer freeze is unnecessary. The testers notify the change-control officer through the CR that the Test branch is ready to move to Production:

Your change control system now looks like this:

CR#	App	Description	Status	Assigned
CR001	Beanz	Build new Beanz system	Test	Change control
Task	Application successfully tested. Please migrate application to Production environment.

 

Next, the change-control officer (not the lead developer, as is the case when moving from Development to Test) uses the Oracle JDeveloper Versioning Navigator window to create an SVN branch at Beanz\branches\test to Beanz\branches\production.

The result is the following representation in the Version Navigator:

(Alternatively, the change-control officer could use Beanz\tags\CR001 to create Beanz\branches\production, based on the assumption any changes made to Test should have been synchronized with CR001.)

The change-control officer uses Oracle JDeveloper to check out the Beanz\branches\production complete code as a working copy and then creates an EAR file using the Production deployment descriptor. (The EAR file needs to be recreated because it's assumed that the Production branch might have been modified during testing, due to bugs and fixes required, as described in the last section.)

Similar to the first migration to Test, the change-control officer uploads a copy of the EAR file to the CR for the Production Oracle WebLogic Server administrator, who then deploys and configures it. Your change control system now looks like this:

CR#	App	Description	Status	Assigned
CR001	Beanz	Build new Beanz system	Test	Prod Oracle WebLogic Server admin
Task	Please migrate EAR to Production environment.

 

The change control officer will also update the change request CR001 documentation that the code to be deployed to the Production environment now exists under the Beanz\branches\production SVN directory.

Upon completing the migration to Production, the Oracle WebLogic Server admin assigns the CR back to the change-control officer:

CR#	App	Description	Status	Assigned
CR001	Beanz	Build new Beanz system	Test	Change-control officer
Task	Application migrated to Production. Please sign off CR.

 

Once informed that the migration has been successful, the change-control officer marks the related CR as complete/in Production.

CR#	App	Description	Status	Assigned
CR001	Beanz	Build new Beanz system	Production	N/A
Task	N/A.

 

Further CRs Moved from Development to Test to Production

As further change requests are raised for the application, they typically follow each other in a sequential fashion, with each created as tags, and in turn migrating through the Test and Production branches using the same method described previously for the initial migrations. For example, if our application has reached CR004, we’d expect to see the following under the tags tree:

As an example, in the following Versioning Navigator figure, CR003 has reached Test, while CR001 has reached Production:

Note how it’s not necessary to keep a copy of all the CRs that have reached branches\test or branches\production. This is because the tags structure keeps a complete record for us. This does raise the question “why bother keeping a copy of a CR in branches\test or branches\production when the CR is contained within the tags directory?” Predominately, the answer is to clearly identify which release has reached which environment, be it Test or Production.

As CRs are migrated to branches\test or branches\production, the previous CR can simply be deleted by using the right-click option:

Bugs Found in Production: Emergency Fixes

While the system is in Production, it's expected that bugs will be found that could require an emergency fix (a.k.a. a hot fix). It's expected that a change request is raised to encompass the hot fix’s solution, let’s say CR068.

Similar to what was described in the "Testing and Changes that Result in Merges back to Development" section, it's expected that the developer assigned to the bug will check out a working copy of the Production branch code. Ideally, the developer should identify the problem and the offending code and change the source code to create a fix. At this stage, where and how the fix is applied must be decided.

It is not appropriate that the hot fix be applied directly to the Production branch because it needs to be tested first. All fixes must at least go through a test cycle.

Alternatively (but this is not ideal), the fix could be applied to the current Development branch to be captured in an upcoming release that goes through the development-test-production cycle. This would be suitable if the fix was not critical and the users could wait. However, if the fix is an emergency fix, it will not be suitable because there might be a number of other CRs that proceed the trunk that require testing first .

The solution in this case is that the working copy should be added to repository as tag CR068 by the developer. The change-control officer then creates an EAR file and gives it to the Test Oracle WebLogic Server administrator to deploy and configure. Beyond this, the release (tag CR068) will go through testing and then exactly the same process as the "first migration to Production" scenario.

For emergency testing, in this case, it would probably be best that the EAR file was applied against a separate Test Oracle WebLogic Server instance because overwriting the current Test Oracle WebLogic Server instance application might be disruptive to current testing and the overall workflow.

At conclusion, the developer must also merge the CR068 changes back into the Development trunk and potentially into the existing Test branch and associated CR tag; otherwise, the fix will be lost when later CRs are migrated to Production and the same emergency might occur again.

Summary

In this fourth installment of five we have investigated the final change control scenarios of migrating our code from test to production, and also considered further CRs that span the whole development, test and production workflow. In the next chapter we depart considering the Subversion scenarios, and instead consider the areas of ADF application architecture, including ADF Libraries, and how they fit into the overall change control process.

Go to Part 5 | 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.