Articles
Application Development Framework
Series: Adapting Oracle Application Development Framework and Subversion to Your Enterprise’s Needs
Part 2: Team Roles, Change-Control Workflow Scenarios, and the Initial Oracle ADF Build
by Chris Muir
This is Part 2 of a five-part series on adapting Oracle ADF development and Subversion to your enterprise’s needs. It covers:
The team roles in change control
Change-control workflow scenarios and the initial ADF build
Development when multiple developers come on board
Team Roles
As we work through the change-control scenarios in this document, a number of team roles will be identified. This section provides an opening summary of the team players to clearly articulate the roles required in a system's lifecycle. Additionally, this section should be read with the upcoming scenarios section to clearly understand the need for the following roles and their responsibilities:
SVN administrator—responsible for the set up and ongoing maintenance of SVN.
Lead application developer—responsible for maintaining the SVN <app>\trunk, tagging the trunk code, and branching the trunk code to the <app>\branches\test branch for a single application.
General developers—responsible for working with the SVN <app>\trunk and their own working copies of a single application.
General testers—responsible for testing the application when it hits the Test environment.
Change control officer—responsible for the creation of EAR files from the SVN <app>\branches\test branch or the <app>branches\production branch for a single application.
Test Oracle WebLogic Server administrator—responsible for installing EAR files and configuring the deployed application on the Test Oracle WebLogic Server.
Production Oracle WebLogic Server administrator—responsible for installing EAR files and configuring the deployed application on the Production Oracle WebLogic Server.
Note that it is possible for one staff member to have multiple roles.
Change-Control Workflow Scenarios
The following sections detail typical workflow scenarios that occur as a new Oracle JDeveloper Oracle ADF greenfield development commences and code moves through the Development, Test, and Production environments, as supported by SVN.
Initial Oracle ADF Build
A new change request (CR) is raised to commence work, for example, CR001. In your favorite change-control system, you will have raised an entry as follows to track the developers' work:
CR# | App | Description | Status | Assigned |
CR001 | Beanz | Build new Beanz system | Development | Developers |
Tip:
In addition to Oracle JDeveloper’s SVN integration, team development is enhanced through the introduction of the Team Navigator as part of Oracle TPC, which provides integration with multiple ALM repositories—such as Change Control, Issues, Bug Tracking—allowing users to create, query, and update artifacts in those repositories from within Oracle JDeveloper. Additional services, such as collaboration and contextual linking of work items through tags and relationships, enhance the productivity of users. Context information about Development files can be saved against a work item and restored by the user.
Using Oracle TPC is outside the scope of this article, but you can find information about Oracle TPC at the Team Productivity Center page on the Oracle Technology Network (OTN). |
A lead developer in Oracle JDeveloper 11g first creates a basic Oracle ADF Fusion Application with both a Model and ViewController project. This is done on the developer's local machine.
This application is then imported into the empty SVN Beanz\trunk by selecting the Versioning > Version Application menu. This opens the Import to Subversion wizard:
In step 2 of 6 for the selected repository connection, select the trunk branch to import the existing application into:
Step 3 of 6 defaults to the application’s root directory, where the source code will be imported from. Comments should be entered for all repository operations, including this initial import of the application.
The remainder of the steps can be skipped, accepting the defaults. The SVN Log window shows the SVN operations undertaken with the repository:
And finally, since an immediate working copy checkout occurs by default, the Application Navigator displays the versioned file icons next to each file:
The files checked in to the SVN repository are reflected in the Versioning Navigator:
Initial Development by Multiple Developers
As new developers come on board, they will check out their own working copy of the application from the Beanz\trunk to their local PC. Each developer’s working copy follows the concept of a sandpit where the developer builds and modifies the application on a local PC.
In the Oracle JDeveloper Versioning Navigator, right-click the trunk directory under the application, and select the Check Out menu. This presents the Check Out from Subversion dialog, which allows you to specify where to place the code locally:
Tip:
There is one further caveat with regards to Oracle ADF libraries and how they are attached. This topic is addressed later in the article. |
The result is you will see the application in the Application Navigator with the change-control icons, much like what the lead developer sees:
Essentially, the Development code is shared with other developers through the SVN repository under the Beanz\trunk directory.
Developers follow the practice of committing their changes and getting new fixes from other developers in the repository by updating their working copy or, alternatively, frequently deleting their local working copy and checking out the complete latest version to ensure that they have the latest copy of all files. The following diagram describes such a check-out, change, and commit scenario:
Tip:
 |
Tip:Oracle ACE Director John Stegeman provides the ADF Essentials about working with Subversion, including checkouts, commits, merges, and more, which is a recommended read for all developers intending to use SVN with Oracle JDeveloper. |
It is assumed during this period that developers will be testing their application using the inbuilt Oracle JDeveloper WebLogic Server or using a Development deployment profile to deploy their application straight to the Development Oracle WebLogic Server via Oracle JDeveloper. In fact, this effort constitutes the majority of the developers’ effort, contrary to the change-control effort described in this article.
Summary
In Part 2 we have investigated what the different staff roles are for maintaining our change control process, and then our first look at different change control workflow scenarios, specifically kicking of an ADF development build into Subversion. In the next installment, once our ADF development is complete, investigates migrating the application to our test environment, and how that is catered for in Subversion.
Go to Part 3 | 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.
Printer View