Configuration Management Features and Capabilities of Oracle Designer
Oracle Designer offers substantial new configuration management capabilities utilizing the Oracle Repository. This presentation will provide an overview of the new configuration management functionality and how it can best be utilized to provide a robust application development environment.
One of the primary benefits of using Oracle Designer is the ability to share existing knowledge between applications. However when new functionality needs to be added to the repository and existing applications have already been defined serious configuration management issues can arise. What used to work may suddenly exhibit new and unintended features. A well planned configuration management plan coupled with the new features of Designer 6i can help to alleviate most of the problems associated with revisions and derivations of applications.
Configuration Management coordinates the resolution of software development issues by identifying and controlling the problems that confront software development teams. Maintaining multiple incremental releases of software inevitably causes them to diverge from each other meaning that even with the best of intentions a seemingly identical change made to two versions of an application many times result in two different results. Over time the discrepancy between versions grows wider as new features are introduced that may not be included in the original version. Without control over existing releases with their bug fixes and new release that introduce added functionality the ability to rebuild prior versions becomes difficult or impossible. Manually maintaining the identification and maintenance of existing versions becomes increasingly difficult as new versions are released. As additional versions are introduced it is increasingly likely that a modification will not be propagated or retrofitted which may introduce bugs or result in a loss of functionality.
Sharing data and information between Designer applications presents many benefits. The ability to maintain information in one place reduces overhead and eliminates having to determine which information is correct or the most up to date. For example if the length or type of a field needs to be changed many applications, modules and databases may be affected. In traditional development environments manually identifying where the required changes need to be made is a daunting task, ensuring the modification is made everywhere it is needed is even more difficult. The ability to automatically perform impact analysis to determine the scope of a change quickly and accurately benefits management and designers when they need to estimate the resources required to implement a change and developers who may have to grope through a variety of systems to locate all occurrences that need modification.
Simultaneous updates are another problem that offer many pitfalls. If Sally is modifying a module and Frank needs to fix a bug in the same module the likelihood of Franks bug fix being overwritten by Sally’s enhancement is high. Without a configuration management procedure in place the communication needed to keep everyone informed with all modifications being made is nearly impossible.
Through this paper and the accompanying presentation examples will be shown and solutions described illustrating how Oracle Designer 6i and the Oracle Repository provide many of the requirements of a sound configuration management system. Using this information you will be better equipped to develop a configuration management framework to control objects within the Oracle Repository.
Consider that a three person team only has three communication paths. However adding a fourth team member doesn’t just add one more communication path it raises the number of communication paths to six. Imagine adding a fifth developer! Frequent team meetings somewhat alleviate this problem, however it is all too often true that the meetings are not frequent enough, don’t cover all of the necessary issues or may be impossible due to teams being separated geographically.
The nomenclature and concepts of the Oracle Repository and Designer 6i
The Oracle Repository and Designer 6i introduce many new terms and concepts; Containers, Configurations, Workareas, Merge, a new check in/check out mechanism, synchronization with file systems just to name a the most common associated with Configuration Management. In the past there were only two kinds of element types used to store information about Applications in the Repository, Primary Access Controlled elements (PAC) and Secondary Access Controlled elements (SAC). The following descriptions will provide a framework of knowledge about the new terminology and their function.
With the new functionality of being able to version and work with many objects at the same time for different purposes, a means of organizing these objects into a manageable size was needed. A new versionable and transferable construct called a Container was created for this purpose. Containers are similar to directories in a file system they provide a way to organizing repository objects in a logical fashion.
Containers can be of two types depending on how the repository is utilized, folders and application systems. If the repository is used only as a source control system Folders are available. If Designer is used for application development then Application Containers and Folders can be used. Application Containers are very similar and have the same appearance of an “Application” in prior releases of Designer. Folders on the other hand are totally new in this release and provide a means to upload and version external files and documents. It appears though that technically they are identical under the covers since typical application objects (modules, entities…) can exist in folders and external documents (word, excel) can exist in application containers. New versions of containers are created when objects are added or removed from it, or if changes are made to the properties of the Container. Containers can contain totally different objects or exactly the same objects as another container only diverging when a modification is made.
A group of versioned objects are specified to exist in a configuration. An object can exist only once in a configuration but it may exist in many different configurations. This graphic from Designers Help depicts two different configurations and show that a configuration can itself be versioned and tracked as an object.
A configuration provides a method of tracking releases of a set of objects at a specific time (or state).
An object version included in a configuration is considered a member of that configuration. They can be added, modified or removed to create new versions of the configuration. A Configuration can also be created and defined via one of the following rules: include/exclude folders or objects, latest, latest before and between, another configuration.
Development shops typically have more than a single developer. These developers certainly find, on occasion, that they need to modify or enhance part of an application that another developer is also modifying. Separate Workareas provide a means for concurrent access to objects that can later be merged into a configuration or serve as a basis for a new configuration. Additionally in the case of large applications with thousands of modules a developer probably doesn’t need or want to have every one of those modules in their development area. A Workarea provides a mechanism of organizing the objects that the developer is currently interested in thereby removing the clutter of the other unneeded objects. Workareas are non-versionable objects that serve as a context for all work performed until a sessions ends or the user decides to change work areas. By specifying access control on the work area they can be configured to be private for a specific developer or testing team or open for access to everyone.
Designer provides several methods to control locking, checking in/checking out and merging of objects in the repository for example:
Mary checks out MODULE01 and locks it
Bob checks out MODULE01 and begins updates on it
Bob attempts check in MODULE01 but cannot unless a new branch is created
Strict locking prevented new modifications to be made on an object until the locking check out has been released. When Mary checks MODULE01 back in releasing the lock, Bob will then have to merge in his changes to be able to allow a check in of his work.
Another possibility would be for Mary to not lock the module on checkout this would allow Bob to have checked out MODULE01 updated it and checked it back in. Now Mary would have to Merge her modifications in with the modifications Bob made.
Versioning as it was known in past versions of Designer is very different with the new Oracle Repository. Gone are the Dummy Applications and Skeletons created to try to keep everything in sync through versioning and exporting. The repository maintains the associations and properties of old configurations without the baggage of Dummy and Skeleton applications through fundamental changes to the underlying database structure of the repository (hence the somewhat high overhead double repository upgrade process). This new versioning concept is succinctly described by the Designer on line help and is provided here for reference and definition:
“Version control is the process of maintaining multiple versions of software development objects and is the most basic requirement for a software configuration management system. The Oracle Repository manages all repository objects, and any kind of file and directory. This enables tracking of changes to the source model, as well as tracking the changes to the contents of individual files. Version control of any element within the Repository will not commence until the element has been initially checked in. Thus if no elements have been checked in then no versioned objects will exist within the Repository and the existing Designer tool set will behave as it does in previous releases.”
While an object is checked in it is write protected and, therefore, cannot be modified. The object must be checked out before it can be changed. Each time an object is checked back into the repository, its version number is updated (for example, version 1.0 becomes version 1.1). In this way, Oracle Repository can keep track of every change that is made to an object, so that exactly the right version of the object is used when creating the application. As an object evolves from one version to the next, a graphical representation known as a version tree also evolves:”
Version Event Viewer
Here is a graphic example of multiple Branches of development for a module but it is important to remember that non-repository objects contained in folders can be versioned and displayed as well.
The Repository has the capability of maintaining versions of non-repository objects and files. Through an upload files can be copied from the file system into the repository. When the file needs to be updated a copy is made to the file system (even if editing was invoked from within Designer) and once updated the Repository provides an upload and synchronization mechanism to keep the Repository up to date with the modifications.
These following checks are done during a synchronization
|Repository copy||File system copy||System Action|
|Unchanged Checked in||Changed||Hijacked file – displays dialog for user intervention|
|Unchanged Checked out||Changed||Uploads copy from file system|
|Changed||Unchanged||Downloads copy to file system|
|Changed Checked in||Changed||Displays dialog for user intervention|
|Changed Checked out||Changed||Displays dialog for user intervention|
If a file is updated and has not been checked out it is called “hijacked”. The options available to reconcile this situation are to checkout and download the repository copy, overwriting the changes made to the file system copy; or to just check out the repository copy thereby allowing for an upload of the updated file system copy; or if parsers are available to merge the files. These options are presented automatically whenever the Repository recognizes that modifications have been made to a non-checked out file.
Here are some informative notes from the Designer help files about synchronization:
· If you delete the repository copy but not the file system copy before synchronization, the repository copy reappears on synchronization. This is because in this case it is treated as a new file and uploaded accordingly. The same applies if you exclude the repository copy from your workarea.
· If you delete the repository copy but not the file system copy after the two have been synchronized, subsequent synchronization operations offer you the choice of deleting or retaining the file system copy. The same applies if you exclude the repository copy from your workarea. If you choose to retain the file system copy, on subsequent synchronization the repository copy reappears. This is because it is treated as a new file and uploaded accordingly.
· You cannot synchronize a file system file with a shortcut reference (denoted by the icon).
· Users of UNIX systems cannot synchronize a repository-hosted file with a symbolic link on the file system
Merging repository objects
When an object has been modified more than once for concurrent changes to multiple configurations Designer allow the objects to be merged together. There are three components involved in a merge a “target” and a “source” and a “common” ancestor version. During the merge internal rules are used to create a result based on changes found in all three versions. The target version is updated and becomes available as a new version when it is checked back in.
A comparison of two module versions Selecting the Source for a Merge Selecting the Target
The Oracle Repository has the capability to store and version objects created by other applications. Word, PowerPoint, ASCII text or graphic documents in fact any file that can exist on the file system can be stored and version controlled in the Oracle Repository. There are limitations on merge comparison of binary files and without parsers many other type of files may be difficult to distinguish differences.
To accomplish this a file system directory is mapped to a Repository Folder. The file system contents can then be loaded directly into the Repository. After check in there is no need to keep the file on the file system as it can be checked out of the Repository whenever there is a need to update it. Removing it from the file system also prevents inadvertent updating of non-checked out files, which would result in the file being considered “hijacked”. If a hijacked file is detected the “Resolve synchronization errors” window is invoked
One of the options is to compare the files for differences by which is accomplished by opening a viewer that highlights the differences between the files. A determination can then be made to; upload the file from disk, overwrite the file on disk with the repository copy or merge the two files.
There are many new constructs, terminology and functionality involved with configuration management using Designer 6i and the Oracle Repository over past releases. They provide for many of the requirements of a sound configuration management system. By developing a configuration management framework to control objects both inside and outside the repository then problems associated with unintended modifications, lost code, missing documentation can be avoided without impacting productivity. During the accompanying presentation to this paper each of the described components will be demonstrated to show how they are related and can be used to help provide a stable design and development environment.
Copyright © 2000,2001 by Scott Nelson
Filed under: Technical Tips
Like this post? Subscribe to my RSS feed and get loads more!