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
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.
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.
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:
Build new Beanz system
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:
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:
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:
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.
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.