by Chris Muir
This is Part 1 of a five-part series on adapting Oracle ADF development and Subversion to your enterprise’s needs. It covers:
Enterprise software development has its own challenges. Enterprises in addressing these challenges have introduced and customized change control systems to their unique needs, maintaining multiple environments for development, testing and production systems, and staff dedicated to maintaining and administrating all of this in a controlled fashion. All of these "shadow" systems and staff provide essential services behind the scenes for enterprise IT departments, though rarely seen or appreciated by the users themselves.
With a huge array of existing systems and competing technologies to manage, the last thing an enterprise wants is for contemporary technologies, such as Oracle JDeveloper 11g and Oracle ADF to “go against the grain” of how system change is maintained. Luckily, through the adoption of SVN as the primary File Version Control System (FVCS), Oracle JDeveloper systems can integrate an extremely flexible system into their existing change-control systems.
This article goes beyond simply explaining how to use SVN with Oracle JDeveloper to consider the whole gamut of how SVN can be used and adapted to enterprise development processes. The article outlines a proposed use of SVN in a greenfield Oracle JDeveloper/Oracle ADF development project, specifically highlighting the different scenarios that occur to promote a system's code through Development, Test, and Production.
This article is designed to assist development teams, administrators, and change-control teams in understanding the processes that exist and need to be followed, the complete set of roles and responsibilities within the change-control processes, and the outcomes. The goal of this article is to not only show how SVN and Oracle JDeveloper can be adopted in your organization, but also to give your staff enough information to manage the lifetime of changes that can occur in an Oracle ADF development environment.
Enterprise development is intrinsically different from shrink-wrapped software development in a number of ways.
Typically, enterprises support system Development, Test, and Production server environments (if not more), which allows them to clearly separate phases of a system's lifecycle. The development environment is where developers build new systems, extend systems, fix existing systems, and tinker for their own purposes. A separate Test environment is where quality control teams install and test the developers' end product against the system requirements to ensure the system is fit for use. Finally, Production servers exist on which the well-tested systems are migrated to allow end users to work with the system to solve the business problem at hand.
Keeping track of where a system's code is—that is, which environment it has reached—is the charge of a file version control system (FVCS) and an enterprise's change-control team. Ideally, the overall task is process driven by a clear set of scenarios that dictate what steps need to be taken to promote code from Development to Test and, ultimately, to Production. Following the processes allows enterprise staff to know the state of the system and which code—be it development code, bug fixes, hot fixes, or even experimental code—exists where.
Shrink-wrapped software is always interested in the next release of a few core products, while enterprises are always managing multiple change requests across an array of systems, technologies, processes, and environments. For enterprises that have a complex array of systems, change-control systems are seldom thought of as the “sexy” part of IT, but these systems are critical for day-to-day IT business by driving how and when work is undertaken.
Change control, sometimes referred to as change management or configuration management, ensures that changes to both software and hardware systems are implemented in a controlled and coordinated manner. In addition, change control provides the ability to identify sections of work to be done in the future as well as work that was done in the past. By their very nature, change-control systems are large and cumbersome, and they are often legacy systems on which little is changed besides minor tweaks to processes, because any change can mean disruption to the maintenance and extension of the core systems that keep the enterprise’s business running.
A typical change-control system tracks Change Requests (CRs) that have an associated ID. CRs are raised for one of three reasons:
Bug fixes to existing systems
Requests for new system development
Requests for the extension or enhancement of an existing system
Most IT departments have tens, if not hundreds or thousands, of CRs in various degrees of resolution at any one time, and requests for change are spread across their entire set of systems.
Oracle JDeveloper 11g presents one of the most powerful Java frameworks for Web development: Oracle’s Application Development Framework (Oracle ADF). Oracle ADF under the 11g banner introduced the concept of the Task Flow, a unique coding paradigm for dividing your Web application into processes. Each Task Flow represents a set of screens that can be reused throughout your application, passing in and passing out parameters and taking the user through a set of defined interactions. The power of Task Flows is greatly enhanced through Oracle JDeveloper’s ability to reuse Task Flows among disparate master Oracle ADF applications, an exciting level of reuse not seen before in Web development frameworks.
Yet this power creates a challenge to an enterprise: Applications used to be seen as a single entity that could be tracked as one core system, but the Task Flow mini-applications introduce a much finer granularity of system management and, through their reuse, a headache in tracking the version dependencies between the master applications and the mini-Task Flows.
With both the unique challenges of enterprise development and Oracle ADF development, this article will consider a method for using SVN that will track an Oracle ADF system’s lifecycle and all its Task Flow components as they migrate through Development, Test and Production environments.
This article dictates the use of SVN in a prescribed manner. Readers should realize the following important points when assessing this article for their own needs:
Once the processes are adopted in your organization, it’s essential that your organization doesn’t veer from the described steps; otherwise, the overall processes will break. In many cases, each step relies on the previous step’s successful execution.
A main attribute of SVN as an FVCS is its flexibility. SVN can be modified and adapted to fit all sorts of requirements. How one organization adopts and uses SVN can be totally different from how another organization uses SVN. While reading this article, you need to assess whether the methods prescribed in this article fit your requirements. Only you can make that judgment, so fully understanding what’s described is important before making any conclusions about what this article prescribes.
Before continuing, it’s important to understand that this article makes a number of assumptions around the following concepts:
Oracle JDeveloper version
Oracle ADF applications, workspaces, and projects
Your Subversion knowledge
Subversion repository layout
This document assumes you're using Oracle JDeveloper 11g R1, specifically the Studio Edition Version 184.108.40.206.0 build 5536.
To make this article useful, there is a balance between attempting to keep the article readable by introducing easy concepts in a logical manner and presenting issues that real-world development teams encounter.
To keep the article simple, initially it is assumed that there is only one master application, implemented through an Oracle JDeveloper workspace. The Oracle ADF application (known as a Fusion Application in the 11g parlance) splits the application into two normal default projects, namely the Model and ViewController. It doesn’t make use of Oracle ADF libraries.
To mirror real-world Oracle ADF development, in subsequent sections of the article, the master application makes “reuse” of one separate Bounded Task Flow (BTF), which is treated as an application in its own right and loaded into the master application via the Oracle ADF libraries feature. This adds extra, needed complexity to the SVN processes described in this article.
This article assumes that your enterprise maintains three environments, Development, Test, and Production, as follows:
A Development Oracle WebLogic Server plus a Development RDBMS
A Test Oracle WebLogic Server plus a Test RDBMS
A Production Oracle WebLogic Server plus a Production RDBMS
This tiered setup is common at many enterprises. Typically, an enterprise’s change-control processes and workflow exist to support this setup. You are free to extend this environment model with further tiers by simply expanding the scenarios spelled out in this article to cover additional tiers.
This document assumes you understand the SVN concepts of the trunk (or head or main), branches, tags, repository, revisions, adding, updating, committing, and merging. For more information on these concepts see O’Reilly’s Version Control with Subversion.
In addition, this document assumes that as a sideline to SVN as a file version control system, you also have a change-control system that tracks the movement of code between environments and who code is assigned to.
Typically, developers share an existing Subversion repository on a central server. Subversion supports access to the repository through a number of different mechanisms, such as a direct connection to the file system on your local network all the way to a dedicated SVN-HTTP server. Oracle JDeveloper 11g R1 supports connecting to any 1.6 SVN server. The discussion of the setup and configuration of such a server and file repository is beyond the scope of this document, though it deserves careful consideration because optimal access to the repository is critical for multi-developer teams. More information on working with Subversion can be found in the book Version Control with Subversion.
|A repository can be created via Oracle’s JDeveloper 11g R1 selecting the Versioning menu's Create Local Repository option opening the Create Subversion Repository dialog: |
From here you can specify the repository's location on your file system, the type of repository, and the connection name created in the Oracle JDeveloper IDE's Versioning Navigator window:
Depending on the type of repository created, a number of preconfigured files are created under the file system location specified in the Create Subversion Repository dialog. Refer to the Subversion documentation for an understanding of what's created.
For the purposes of supporting our greenfield project and Development, Test, and Production environments, the following Subversion repository is suggested:
Here, <app> is the application name, such as a hypothetical application called Beanz for this article. Multiple applications can exist in their own separate directories off <root> with similar subdirectory structures. For the purpose of this document, we'll assume one application.
This structure can be created using the Versioning Navigator by right-clicking the SvnConn connection to your repository and selecting New Remote Directory. This opens the Create Remote Directory dialog where you can create the structure above:
Here is the resulting representation in the Versioning Navigator:
Depending on what you read, some organizations prefer different layouts of their SVN repository, such as the following style, which places the application subdirectory at the leaf end of the tree:
While the author acknowledges these alternative layouts, for the purposes of this article, the layout of the repository is not as important as the change-control scenarios described within. Readers should take time to discover which layout suits their needs.
For the application at hand, as is standard for SVN repositories, the trunk location will be where the Development code resides. The Test and Production branches exist to be the single point of reference for what code is running in the Test and Production environments at any given moment in time.
Typically, no development occurs on the Test and Production branches, but rather fixes to bugs discovered by testers and hot fixes required for the Production system occur on the Test and Production branches. The only time code is copied (sourced) from the Test or Production environments is when the workflows described in this document have not been followed due to human error (or similar scenarios) and it becomes necessary to trust what code is checked in to SVN. Obviously, this is not recommended practice.
The tags directory initially has no subdirectories, but it eventually contains subdirectories for separate releases that essentially contain a complete set of files for your application at a given point in time. This may be releases that currently exist in the Test or Production branches or releases that are historic and kept for versioning and archival reasons.
In this first installment of five we have learned about some the development challenges that confront enterprises beyond just writing code. In addition for the purposes of the article we have a basic ADF application structure, server environments for development, test and production, and a basic Subversion repository. In the next installment we'll discuss the team players in the change control process, and how to kick off an ADF development into Subversion.