Using Oracle Designer 6i to Configuration Management Internet Platform Applications An Oracle Technical White Paper
INTRODUCTION Configuration Management does not normally become an issue within a software development organization until something goes wrong. Bug fixes go astray, previous versions cannot be rebuilt and developers begin duplicating work. These costly and time-consuming problems can only be controlled with a vigorous methodology being imposed on the development process. Such a process can easily add to the cost and time to produce software, but is the only accepted procedure to avoid mistakes. Such a rigorous process will require productivity aids to make it cost effective. This has led to the requirement for configuration management tools that automate and control much of the software development process. Software Configuration Management, like many software terms, is open to wide interpretation. For the purposes of this paper this is considered to cover: object versioning software configuration software delivery Oracle Designer 6i includes object versioning and software configuration; software delivery will be incorporated in a future Release Manager. Oracle Repository consists of a store and a set of management tools for the all the meta data and application objects of an enterprise. The Oracle Designer configuration management tools sit upon the Oracle Repository. This Repository resides within an Oracle database, offering a true multi-user, scalable solution, supporting large development teams. This paper concentrates on the use of configuration management tools in the context of Oracle Designer. The utilities are apply equally to non-oracle software configuration management issues, with access to the version utilities via a command line interface. The paper covers versioning of Oracle Designer elements, files and folders and the configuration management utilities. OBJECT VERSIONING 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. Versioning of existing Oracle Designer elements, such as an Entity or Function is not as simple as it might first appear. Just giving an Entity a version number and locking it so that no further changes maybe made does not consider the structured nature of the data within the Repository. An Entity may have Attributes, a Unique Identifier and Relationships, all of which may or may not require versioning. Within Oracle Designer the concept of a versionable object has been introduced. Such a versionable object would be an Entity with all the items that belong to it. Thus if an existing Attribute belonging to an Entity needs modification the Entity, as the versionable object, would be checked out, the attribute edited and then checked back in to the Repository. The process of checking in the entity assigns a new version label and stops the Entity being edited without first checking it out. 2
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, no versioned objects will exist within the Repository and the existing Oracle 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. Figure 1. Simple Versioning of a Single Element A simple version tree has only one branch, usually called the MAIN branch, as shown in the illustration above. However, a more complex version tree will have several branches, each representing separate parallel development of the object. Both repository and non-repository objects can be version-controlled in the repository. Versions are organized into a version tree structure with branches. Branches have user-defined labels, typically chosen to indicate their role in the development process. All objects can be identified by a systemgenerated version number. Important versions can be assigned version labels by the user to indicate development milestones. 3
WORKAREAS A new concept has been introduced into Oracle Designer to enable a collection of single versions to be viewed. A workarea is defined as a secure area of the repository in which a user can make changes to objects to which he or she has access. This is known as a Workarea and is the first concept existing and new Oracle Designer users will meet in Oracle Designer 6i. Existing Oracle Designer repositories will be upgraded to Oracle Designer 6i into a single workarea. All existing applications within the original repository will appear within this single workarea. By managing the access to elements each user will not be subjected to lists of all versions of all elements within the repository. Figure 2. Workareas as a View onto the Repository As an example, assume that User A wants to work on some of the repository objects that he or she owns. User A checks these objects out, locking them at the same time. The original objects remain in the repository, locked so that no one else can update them until User A has finished. Other users can still view these objects, provided they can access them. User A then works on the objects and, having finished, checks them back in. As soon as the lock is released, other users can check out these objects. It is possible to check out and update an object without locking it, allowing other users to check out the same object and possibly update it as well. In this situation, the first user to check the updated object back in is allowed to do so, while updates from other users are converted to branches which can subsequently be merged with the original updates. It is also possible to set a repository-wide option to lock every object when it is checked out. This option prevents any other user from checking out the object until the first user checks it back in. A workarea is not versionable. That is, you cannot create different versions of a workarea in the way that you can create different versions of repository objects. You can, however, make a copy of a workarea and preserve different workarea states that way. You can populate a workarea by including different configurations, or groupings of specific repository object versions. The set of different configurations is known as the member list. If the resulting workarea specification includes more than one version of a particular object, you can refresh the workarea to resolve the version conflict, according to the order of configurations in the member list. 4
CONFIGURATIONS When you create a configuration you group together specific versions of selected objects, rather like striping or labeling in some configuration management systems. For example, when the development of individual objects reaches the stage where you can build a particular application, you need to specify exactly which version of each object is to be used for the build. The same applies when assembling a set of objects to be used for a test or inclusion in a patch release - the configuration defines which versions of which objects are to be used. A Configuration can consist of individually identified Repository elements, or be defined via a rule. The rules available are: include/exclude folders or objects, latest, latest before and between, another configuration and even a diagram contents. For example, all tables from a particular diagram with a creation date before a particular date could be included in a configuration. This configuration definition could then be used to define the contents of a workarea. A configuration may also be versioned: Figure 3. Versioning of Configurations POLICIES A policy enables a configuration manager to control branching, labeling and locking mechanisms across a development repository. By setting policies you can ensure that specific development branches are not populated with new object versions at critical periods in development, for example during a build. It also ensures adherence to system-specified object version labels. 5
AUTOMATIC BRANCHING When an automatic branching policy is set, all checked out objects are checked in to the default branch defined for each workarea using the Configure workarea dialog box. AUTOMATIC VERSION LABELING When automatic version labeling is set, the user is unable to specify a label for an object version on check in. The repository will automatically assign a label. STRICT LOCKING When strict locking is set, users are forced to lock objects on checkout. Without strict locking the user can choose whether or not to lock an object on checkout. However, locking does not prevent another user from checking out a copy of the same version. It only prevents that user from checking in onto the same branch until the locked version is checked in. Strict locking prevents any version of the object from being checked out from a branch once a version has been checked out since two or more users cannot apply locking to the same branch. VERSION HISTORY VIEWER There are two types of tools that work against the Repository. The Oracle Designer tool set works within the context of a Workarea, thus limiting the view to a single version of any element at any one time. The Repository tools work against multiple versions of elements, permitting cross version reporting and management. The Version History Viewer works across versions showing the history of a single element through time. Figure 4. The Version History Viewer 6
VERSION EVENT VIEWER Each time a new version is created, this is recorded as an event and certain information is recorded against it. This information includes: the type of event, for example check in, check out or merge the version label the date the version was created the branch on which the version resides notes to explain any changes to the version the version number the version status (checked in or checked out) The Version Event Viewer displays the evolution of a repository object in tabular form. COMPARE AND MERGE Once elements within the Repository are versioned then it can be assumed that they will be different to previous versions of the same element. The Repository tools provide facilities to compare and merge elements, whether they are text files or structured elements from the Oracle Designer model. The merge utility algorithm will automatically resolve differences, provided there are no conflicts, and select the appropriate changed item. You can, however, override the selection made by the algorithm if desired. For example, a Column prompt added to a Column definition would, when merged from a branch version to the main branch, take precedence over a blank Column prompt in the Column definition on the main branch. STRUCTURED AND UNSTRUCTURED DATA Existing users of previous Oracle Designer versions are familiar with structured data. For example, an Entity has an association to Attributes, which in turn may have Valid Values. Each Repository structured element has defined properties that belong to them. Unstructured data has no such properties or associations, such data might include Documents, Images, Executables and Runtime code. The storage of structured data within the Repository has been around for many years, unstructured files have been traditionally held in an operating system file. For complete control of application definitions, models and code within a Configuration environment it is necessary to handle both the unstructured and structured data. Unstructured files need to be put under version control. This is achieved in Oracle Designer 6i by loading the file into the Repository and treating the file as a Repository element under the control of versions and configurations. A file system directory is mapped to a Repository Folder, the contents of the directory can then be loaded into the Repository, and checked in. The operating system file could then be deleted and then restored at a later date from the Repository. Synchronization between the Repository stored files and the operating system stored files is also possible. Once a file is loaded into a folder within the Repository it may also be versioned and form part of a Workarea and Configuration. 7
Figure 5. Comparing Two Versions of an Entity Figure 6. Selecting Which Properties to Accept When Merging Two Versions of an Entity 8
COMMAND LINE INTERFACE FOR REPOSITORY AND TOOLS The Command Line Tool gives access to Repository Configuration Management facilities from a command prompt. This enables batch running of the Configuration Management facilities described above. For example, development code files could be loaded into the Repository every night at a set time and checked in to be placed under source code control. The command line utility will be made available across several platforms, removing the Windows based restrictions. The command line tools might also be included within third party tools, enabling the Repository to be used to store and provide a managed data store for such third party products. Two modes are provided: Interactive: jrcmd c username/password -w[workarea name] One Shot: jrcmd -c username/password -w[workarea name] Command In either mode the following command might be entered: diff -loperating_system_file -rrepository_file - fdifference.txt. This would send to the file difference.txt the differences between a Repository stored file and an Operating system stored file. SUMMARY The fundamental requirement of a configuration management system is the ability to identify and control objects as they evolve over time. It must also be able to maintain a history of the changes to an object as it evolves. Individual members of the team should be able to undertake development work without interference from other team members. Then, as each task is completed, the results should be available to other members of the team to include into their own work as and when required. Configuration management tools should also enable parallel development, for example to enable maintenance work while development continues or to allow concurrent development of two versions of the same application. It should then be possible to merge the two development streams into one version to incorporate all the desired enhancements. At appropriate stages in the development cycle, it should be possible to identify specific versions of objects and group them into a configuration, to build a test or release version of an application. Oracle Designer 6i addresses these requirements by providing secure individual workareas, controlled access to configuration management functions and a range of utilities that enable: object version control through checkin and checkout procedures parallel development through branching comparing and merging of objects configurations of selected object versions The above functionality provided through the Oracle Repository utilities extends Oracle Designer fully into the Configuration Management arena. 9
Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. Worldwide Inquiries: +1.650.506.7000 Fax +1.650.506.7200 http://www.oracle.com/ Copyright Oracle Corporation 1999 All Rights Reserved This document is provided for informational purposes only, and the information herein is subject to change without notice. Please report any errors herein to Oracle Corporation. Oracle Corporation does not provide any warranties covering and specifically disclaims any liability in connection with this document. Oracle is a registered trademark, and Oracle8i, PL/SQL, Oracle Designer 6i, and Oracle Repository are trademarks of Oracle Corporation. All other company and product names mentioned are used for identification purposes only and may be trademarks of their respective owners.