Software Configuration Management - Concepts

An Oracle White Paper
June 2013
Concepts - Software Configuration

Management
Oracle Utilities Application Framework
Oracle Utilities Application Framework - Concepts - Software Configuration Management
Introduction ......................................................................................... 2
Caveat ............................................................................................. 2
Conventions used in this whitepaper .............................................. 2
What Is Configuration Management? .................................................. 3
What Is Involved In Configuration Management? ............................... 4
Why is Configuration Management so important? .......................... 6
How to Read this series .................................................................. 7
Configuration Management Concepts ................................................. 8
Configuration item ........................................................................... 8
Base Product ................................................................................... 8
Customization ............................................................................... 10
Baselines ....................................................................................... 11
Versions ........................................................................................ 13
Releases ....................................................................................... 13
Configuration Management Approach .............................................. 13
Guidelines For Effective Configuration Management ........................ 14
Treat each environment like a production environment ................ 14
Management tasks are no different ............................................... 15
Begin with the end in mind ............................................................ 15
Assume an environment for change ............................................. 15
Minimize the number of environments .......................................... 15
Keep the solution simple as possible ............................................ 16
Automate where possible and necessary ..................................... 16
Don’t release unless documentation is complete .......................... 16
Do not assume a tool is a silver bullet ........................................... 16
Other Resources ............................................................................... 17
Web Pages .................................................................................... 17
Suggested External Reading ........................................................ 17
Introduction
Welcome to the Configuration Management series of whitepapers for Oracle Utilities Application
Framework based products. This series hopes to introduce and inform you about the approaches to
implement a strong configuration management approach in your implementation before and after go
live.
This whitepaper is the first in the series and covers the introductory aspects of Configuration
Management. It is recommended that readers be familiar with the concepts outlined in this document
before reading any of the rest of the series.
Caveat
While all care has been taken in providing this information, the advice in this document may or may
not apply to the particular software configuration management practices you may be using at your site.
The examples and general advice should be taken as suggestions only.
It is recommended that each technique outlined in this series of documents be examined in light of
your particular organizational policies and use of the product at your site. If the technique is deemed
appropriate to your site, then consider implementing it. If the technique is not appropriate (e.g.
contravenes site policy and other reasons), then it should not be used.
Scripts and command in this document are provided as is and should be considered as a starting point
for any utilities or facilities you wish to implement.
Conventions used in this whitepaper

The advice in this document applies to any product based upon Oracle Utilities Application
Framework versions 2.1 and above. Refer to the installation documentation to verify which version of
the framework applies to your version of the product. For publishing purposes the specific facilities
and instructions for specific framework versions will be indicated with icons:
Advice or instructions marked with this icon apply to Oracle Utilities Application
Framework V2.1 based products and above.
2
Note: For publishing purposes, the word "product" will be used to be denote all Oracle Utilities Application Framework
based products.
Note: Advice in this document is primarily applicable to the latest version of the Oracle Utilities Application Framework
at time of publication. Some of this advice may apply to other versions of the Oracle Utilities Application Framework
and may be applied at site discretion.
Note: In some sections of this document the environment variable $SPLEBASE (or %SPLEBASE%)
is used. This denotes the root location of the product install. Substitute the appropriate
What Is Configuration Management?

Configuration Management, also known as Software Configuration Management, is a set of practices
that assist in the management of the set of components that constitute a delivery or a product. This
means managing the component from the time is being developed, fixed, tested and implemented so
that the correct version of the component (and its related components) are present in the right places
at the right times.
The ultimate aim of Configuration Management is to deliver a physical product to a customer as agreed
with that customer. In terms of an Oracle Utilities Application Framework based product
implementation that product is a copy of the base product, supplied by Oracle, and all the custom
modifications performed by the implementation. This constitutes the implementation for a particular
customer with the customizations as well as the version having the functionality agreed for that
customer.
Customizations for a customer must fit with the base product chosen for implementation for
compatibility and upgradeability reasons. This concept is illustrated with the puzzle figure below.
Customizations
The Implementation
Base Product
3
Figure 1 – The implementation puzzle
This representation is apt for a few reasons:

• Customizations can overlap base product functionality. For example, you may be replacing a
base provided algorithm with a custom version. Another example is taking a base provided
extract and modifying it for a customer’s purpose.
• Customizations may extend the products functionality. New functions may be added to
extend the functionality for a new customer.
• Customizations must fit into the base product, like a puzzle piece, else there may be
incompatibilities.
The relative size of the pieces of the puzzle will vary in size from customer to customer and even from
release to release. Some customers will have a small customizations piece and others a larger one. The
amount of customization is dependent on how much a fit the product is to the current business model.
This series of whitepapers will focus on the Configuration Management for the customization set of
components as that is the set of component the implementation has the most control over.
What Is Involved In Configuration Management?

Configuration Management is a distinct set of practices that assist in the management of components,
known as Configuration Items, which as a set make up the all the customizations you implement for a
customer. The model used to describe the Configuration Management practices is displayed in the
figure below:
Change Defect Status

Management Management Accounting
Version Release
Distribution
Management Management
Environment Management
Concepts
Figure 2 – Component parts of Software Configuration Management
4
• Concepts – At the base of the model is a set of Configuration Management concepts all the
practices use as a common basis. This part of the series covers this aspect of Configuration
Management.
• Version Management – At the development level it is important to manage and track
individual versions of configuration items. Version Management is the set of processes to
ensure that you can manage and track these items, at a sufficient level, to ensure they do not
negatively impact your ability to deliver or upgrade your customizations. This aspect of
Configuration Management is covered in the Version Management document in this series.
• Release Management – Once the versions are managed a group of configuration items are
assembled into a release to be packaged for distribution. A package can be a single emergency
fix or a whole customization release (and every combination in between these extremes).
Release Management is the set of processes that manage the building and packaging process
ready for distribution. It also deals with how to prepare your customizations for an upgrade.
This aspect of Configuration Management is covered in the Release Management document in
this series.
• Distribution – Once the release package is built it must be distributed, or more correctly,
migrated to the environments it needs to be implemented in. Distribution is the set of
processes to manage the further implementation of the package to the target environments.
This includes how it gets to the environment, how it is installed and retention of the
distribution. This aspect of Configuration Management is covered in the Distribution
document in this series.
• Environment Management – To cater for all the Version Management, Release
Management, Distribution and other activities in the implementation (e.g. Testing, Training
etc), a set of environments is needed to support your activities. Environment Management is
the set of processes to identify, own and manage a set of interrelated environments to support
the successful implementation and support of your product implementation. This aspect of
Configuration Management is covered in the Environment Management document in this
series.
• Change Management – One of the interfaces into Configuration Management is the
integration of change. Change affects all aspects of the implementation and post
implementation and Configuration Management is no different in this respect. Change
Management is the set of processes to integrate and handle change within your Configuration
Management solution. This includes changes from external sources (product and
environmental) such as upgrades, rollups and single fixes. This aspect of Configuration
Management is covered in the Change Management document in this series.
• Defect Management – Another interface into Configuration Management is the impact of
defects found before and after implementation. Defects are specialist types of changes to
address specific issues rather than changes to functionality or changes to the environment.
Defects found invariably mean changes to configuration items and Defect Management is the
set of processes to register and manage the implications of defects on the delivery of
5
configuration items. This aspect of Configuration Management is covered in the Defect

Management document in this series.
• Status Accounting – When a Configuration Management solution is implemented for your
Oracle (Utilities | Enterprise Taxation) product implementation, from time to time
information must be provided from that solution to provide feedback into other project
processes such as Project Planning, Organizational Change Management and Project Status
Reporting for management types. Status Accounting the set of processes to extract metrics
and information from the other processes in Configuration Management to feed external
sources such as plans and status reports. This aspect of Configuration Management is covered
in the Status Accounting document in this series.
Why is Configuration Management so important?

Poor Configuration Management often causes the most frustrating software problems. The problems
are frustrating because they take time to fix, they often happen at the worst time (at the customer site),
and they are totally unnecessary. They often taint all the hard work that has been done already to make
sure the system is functionally correct.
Do any of the following situations apply to you?
• A difficult bug that was fixed at great expense suddenly reappears. if a bug fixed in a particular
version of a program and implemented without tracking, then in future changes you may
introduce an earlier version reintroducing a bug. This can be frustrating for a customer who
thought that a bug has been solved for good.
• You cannot track what code is running in what environment. This can prevent
implementation of fixes and performing upgrades. There is a story of an implementation
where the development team onsite did not keep track of their code since they started
developing. The team basically compiles their code and then transfers the compiled object to
production not tracking which source code it came from. Over the period, it got to the state
where it was almost impossible to determine which version of the source belonged to which
object in Production. Not only does this introduce the risk of reintroducing already fixed
problems back into production, it throws a doubt on upgrading and even taking single fixes.
If a recompile is required by an upgrade or single fix then the risk is exposed and can result in
not taking an upgrade or fix for an issue. The only resolution for this type of situation is to
spend time attempting (i.e. guessing) to identify the correct version of the source for the object
and realigning all the code. This will take time (i.e. in search time and retesting time) and still
not guarantee success as you may not guarantee that the source matches the object.
• Developers are shifted between assignments with or without your knowledge or quit. Tracking
code that particular developers have in progress is important to ensure a smooth transition
and to minimize risk. Failure to track this can result in reduced flexibility and increased project
risk.
6
• The relationships between code and data are not tracked leading to pieces of functionality not
working as expected or not at all. All the Oracle Utilities Application Framework based
products are primarily data driven products, key data has to be provided to the product to
recognize customizations and operate customizations as expected.
• You are unable to track which environment has which release or which patch has been
applied. This can be critical in determining upgrade impact across the environments that a site
has implemented.
• The documentation delivered with the software does not match or is so out of date it is
useless to your customers. Releases include all types of configuration items and if one is not
consistent with the other then misunderstandings and negative impacts ensue.
All these situations (and more) are issues caused by ineffective or non-existent Configuration
Management practices. If you do not experience any of these problems or problems of a similar nature
you are either very lucky, do not have a Configuration Management problem or your Configuration
Management solution is either complete or so simple that is self-sustaining.
Configuration Management helps to reduce (or eliminate) these problems by offering a solution for
tracking and management of configuration items and releases.
How to Read this series

This series of documentation has been designed to educate all roles in an implementation about the
importance of Configuration Management for the success of the implementation and post
implementation. Aspects of the series are targeted at different groups of individuals:
• Managers – Project Managers, Project Directors and Team Leaders.
• Configuration Management Personnel – Configuration Management personnel (managers
and staff who package and migrate packages).
• Architects/Developers/Others – Any other role in the implementation.
The suggested reading order and components that are applicable to different groups are illustrated in
the table below:
TABLE 1 – SUGGESTED READING GUIDE
ORDER DOCUMENT MANAGERS CONFIGURATION OTHERS
MANAGEMENT
1 Concepts ■ ■ ■
2 Environment Management ■ ■ ■
3 Version Management ■ ■
4 Release Management ■
5 Distribution ■
6 Change Management ■ ■
7 Defect Management ■ ■
7
ORDER DOCUMENT MANAGERS CONFIGURATION OTHERS
MANAGEMENT
8 Status Accounting ■ ■
9 Implementing Single Fixes ■ ■
10 Implementing Service Packs ■ ■
11 Implementing Upgrades ■ ■ ■
Note: The ■ icon indicates that that group of people should read that component of the Configuration Management
Series. All groups are welcome to read outside this suggested reading guide.
Configuration Management Concepts

For Configuration Management to be effective during an implementation and after, a number of key
concepts need to be understood.
Configuration item
A Configuration Item is a component (code, data or other) of the implementation managed by
Configuration Management. This can be something developed or acquired by any other means (such as
input directly), onsite or offsite.
The level of Configuration items can get quite detailed with smaller and smaller levels of components
that can be managed individually. The key to a good Configuration Items is choosing the level you
want to manage to exhibit the appropriate level of control. This concept will be discussed in the
Version Management part of this series.
Note: Refer to Base Product and Customization sections of this document for a list of the common configuration items
delivered in the base product and customizations respectively.
Base Product
The base product is the Oracle Utilities Application Framework based product configuration items
delivered by the Product Development team at Oracle. These are delivered at specific intervals in the
form of the initial installation of the product, upgrades, rollups and single fixes. The table below
outlines the common configuration items delivered with the product as part of the base product:
TABLE 2 – BASE PRODUCT COMPONENTS
AREA CONFIGURATION ITEM COMMENTS
Runtime – Software Server Express Application Server Used to execute the COBOL business objects used by the
required to run the product online and background processes.
Base Software – The Base Screen definitions in XML/XSL. Used to define all the screens delivered in the base product.
product itself Base Business Objects All the business functionality used by the online and
background processes expressed in precompiled
executables/classes. This requires Server Express and java
runtime to execute.
8
Base Services All the services supplied with the product that are used to
implement the online functionality.
Base XML MetaInfo All the internal definitions of the base objects that are used
for validation and as a basis XAI schema definitions.
Base Algorithms The compiled and source code (for basing your custom
algorithms upon) for all supplied base algorithms. The
compiled AND source code are considered configuration
items.
Common Copybooks/classes A set of copybooks shared between the base product and
customizations that define the basic interface between the
two.
Base UNIX scripts and UNIX A set of basic UNIX scripts to manage the runtime and
functions development aspects of the product. A common set of UNIX
functions are also implemented to be reused across the
UNIX scripts.
Base Background Processes A set of precompiled background processes. Additionally

some of the source code for interface background
processes are provided to be as a basis for any
customization.
Base GUI Framework A GUI framework is provided to render the screens, use the
XML Meta Info internally and provide interaction with end
users. This also includes the XAI processor.
Multi-Purpose Listener This provides interaction with XAI from non-HTTP sources
and provides outgoing transactions from the product to
external systems/hubs.
Database Base Schema This is the set of tables, indexes, views and sequences that
constitute the database structure that houses the product
data.
Data Base Meta Data This is the set of base data that controls the internal
operations of the product. It is necessary for basic operation
of the product.
Base Control Data This is the set of data that the implementation chooses from
a sample set of control data such as algorithm definitions
and lookups.
Base Demonstration Data This is a set of sample set of data used for training and
familiarization purposes.
Other Base Documentation This is a set of MS word documents and online

documentation (including help and data dictionary) that
supply base information about Business Processes,
Administration and Utilities supplied with the product.
Base Configuration Files This is a set of configuration files that define the
environmental, XAI, WebLogic, WebSphere and Oracle
Application Server configuration templates/files for the
product.
9
Development Oracle Utilities Software This is a set of utilities and guidelines (in MS Word format)
Development Kit that describe how to develop for the product and implement
packaging and migration of code/data.
The following additional environmental components are not provided with the base product but
should be considered as configuration items, as without those the product would not work at all:
TABLE 3 – ENVIRONMENTAL COMPONENTS
CONFIGURATION ITEM COMMENTS
Operating System Used to house the product upon
Java Runtime Used to run the product
PERL Runtime Used for the product management and development scripts and used for Configuration Lab
and Archiving.
Database Runtime Used to manage the product database. Typically this is Oracle, SQL Server or DB2.
Third Party Runtime Any third party product such batch schedulers, print software, etc
Customization
A Customization is any configuration item introduced, changed or removed as part of an implementation
to implement the customers’ business rules, practices and standards. In general the following items are
to be considered configuration items:
TABLE 4 – CUSTOMIZATION CONFIGURATION ITEMS
Data Customization Custom Meta Data This is the data that defines the behavior of the customizations.
Custom Control Data/COTS This is the set of reference data used by the implementation.
Database Customization Custom Schema These are the set of custom tables, indexes, views and
sequences introduced for the implementation.
Code Customization Custom Screens These are the set of XML and XSL that define any custom
screens.
Custom XML MetaInfo These are the set of XML MetaInfo files used to define the
internal Jolt interface and XAI interface for any custom screens.
Custom Client-Side User Exits These are a set of Java Server Pages that allow
implementations to manipulate the base client browser code.
Custom Server-Side User Exits or These are a set of COBOL or java routines that allow
Change Handlers implementations to manipulate the base business object code
not covered by algorithms.
Custom XAI Schemas/XSL These are the set of custom XAI schema definition files and XSL
scripts used to manipulate data into and out of SPL CC&B.
Custom Business Objects These are the set of custom COBOL or java based business
objects that implement custom code. Typically these are used by
Custom Services and Custom Background Processes.
Custom Background Processes These are the set of custom COBOL or java based programs
that drive the custom background processes.
10
Custom Algorithms These are the set of custom algorithms that are used in place of
base algorithms.
Custom UNIX Scripts These are the set of custom UNIX scripts to provide additional
management and execution capabilities.
Custom Help These are the set of HTML files that are invoked when a user
requests online help. They can be customizations of base help or
additional custom help.
Custom Data Dictionary pages These are the set of HTML pages exposed by the Application
Viewer to view programs and/or data dictionary information for
the implementation.
Other Custom Batch Schedule This is the background process schedule expressed in the
chosen Batch Scheduling tool.
Custom Documentation This is set of additional documentation (in your chosen format) to
use in the implementation (e.g. Specification, Training Guides,
Operating Manuals etc).
Baselines
A baseline is the sum of completed configuration items at a point in time. That point in time will usually
be around a release event, upgrade or significant date (such as coinciding with a phase of the
implementation). At that point the relevant configuration items are prepared for release and become
the new base on which each subsequent release is based against. Baselines can be automatic (triggered
by certain events) and non-automatic.
Baselines are important as they provide a realization that the base of an implementation can move
during an implementation so that rework is not necessary (i.e. by considering previous baselines). For
example, when an upgrade of the base product arrives on site, that new version becomes the new base
for any future work. Older baselines become obsolete and can be effectively forgotten. This is
important as it affects release retention (This will be expanded upon in Release Management). Baselines
become restore points in case of problems.
In any Oracle Utilities Application Framework based product implementation there is in fact are two
distinct streams of baselines:
• Product Baseline – This baseline is associated with product releases and upgrades. A product
baseline is a copy of the base product at a certain release level and associated patches.
Note: A single fix release is not a baseline as the original version of the product is required for the single fix to
be applied against. The combination of the base and patches becomes the baseline, not the single fix on its own.
• Customization Baseline – This baseline is associated with the customizations implemented

during an implementation and post implementation.
The Product Baselines and Customization Baseline are closely associated by the fact that when a
Product Baseline is taken the Customization Baseline must be taken. This is because the configuration
11
items in the Customization Baseline use some of the Product Baseline items. For example, Base
copybooks are used in customizations to provide interfaces to base modules.
It is very easy to confuse baselines with releases as baselines are associated so closely with releases but
there is an important difference. Once a baseline is taken all previous baselines become obsolete, where
releases can always be reversed out if needed (this idea will be expanded in Release Management).
In terms of effort baselines are not much extra effort on an implementation:
• A Product Baseline is considered taken when you install the new base version or upgrade with
all its follow-up consequences (recompilation of customizations etc). All past versions, that are
not active, now become obsolete for basing any customizations against.
• A Customization Base is considered taken when you recompile all customizations and do not
wish to retain older releases, which are not active. All subsequent work on customization is
based upon that release.
These principles have been incorporated into the processes and principles outlined in Release
Management.
Automatic baselines
There are a certain number of situations that, by their very nature, dictate that a baseline be taken
automatically. When this occurs, refer to the Release Management section on what needs to be
performed.
TABLE 5 – AUTOMATIC BASELINES
PRODUCT BASELINE AUTOMATIC BASELINES CUSTOMIZATION BASELINE AUTOMATIC BASELINES
Initial installation (before customizations are performed). Initial delivery of customizations to customer
Mandatory Rollup or upgrade Major releases of customizations to customer
Upgrade of version of database or operating system as this

requires a new installation download
Upgrade of version of database or operating system as this requires a new installation download from
edelivery.oracle.com or My Oracle Support.
Non-Automatic baselines
During an implementation other events may required a baseline to be taken for customizations
(Product baselines are generally automatic as they are dictated by someone else). Whether a baseline is
taken in these situations is up to the Development Manager, Project Manager and/or Project Director
considering whether past baselines are still valid.
Situations that generate a potential Customization baseline include:
• The release of an important piece of functionality that is significant in functionality terms but
is not considered a major release (due to size).
• An operating system or database patch that is considered significant.
12
• A single fix from base product that includes changes to copybooks used by customizations.
• A significant data event such as completing the loading of control data.
Versions
A version is a particular variation of an individual configuration item. The processes employed to
manage these versions is outlined in Version Management. Versions are usually managed at the
development level.
Releases
A release is a collection of configuration items ready for deployment associated with a baseline or any
release event including bug fixes (also known as emergency releases). The processes employed to manage
these versions is outlined in Release Management. Releases are managed at the configuration level and
become the unit that is tracked once built.
Configuration Management Approach

During implementation and post implementation the Configuration Management Approach can be
summarized as follows:
• The configuration items from the customization (as outlined in Customization) are built using
the relevant tools. The items are version controlled and stored in a configuration management
repository. This is the realm of the development team who can use the repository to track the
correct versions for the work they are performing (e.g. fixes, upgrades or functionality
releases) and mark the relevant items as ready. This aspect of Configuration Management will
be covered in the Version Management part of this series.
• The contents of a CM package will be influenced by what changes are to be implemented and
what defects are found during testing and post implementation. These aspects of
Configuration Management are covered in the Change Management and Defect Management
parts, respectively, of this series.
• When ready, the relevant configuration items are extracted from the repository and placed
ready for packaging into a release or a single fix. The process includes the extract, transfer and
packaging process to produce a releasable unit known as a CM package. Typically, the CM
package for a release a sum of all the customizations, including data, up to the current date.
This aspect of Configuration Management will be covered in the Release Management part of
this series.
• A set of environments are established to support all the activities required in the
implementation and any support activities after implementations. These will need to receive
CM packages as required. This aspect of Configuration Management will be covered in the
Environment Management part of this series.
13
• Once a CM package is available and set of environments are established the CM package will
need to be distributed and installed in these environments according to local conventions and
processes. This aspect of Configuration Management will be covered in the Distribution part
of this series.
• To check on all of the aspects of Configuration Management to ensure that the relevant CM
packages contain the relevant items and the CM packages are implemented into the relevant
environments at the correct times a set of processes to audit and report the progress are
required. This aspect of Configuration Management will be covered in the Status Accounting
part of this series.
Guidelines For Effective Configuration Management

The following are a set of guidelines to guide you in designing and using a better Delivery Management
solution. Each of these guidelines should be somehow incorporated into every procedure and plan that
you build for Delivery Management in your project.
Treat each environment like a production environment

This principle may seem obvious but when designing a solution this principle is often ignored. When
you design any procedure to use in the Delivery Management it is a good idea to assume that every
environment is a production environment for the following reasons:
• It tests the procedures from early stages in lifecycle rather than at the later stages. For example
if you treat your test environments as a production environment then the same (or similar)
migration or change procedures would be used, as for production. When the production
migration happens the procedures would be used, tested and hopefully all problems ironed
out. If you contrast this with having different procedures for test and production you will
have no opportunity to test but in the customer environments. If there any problems then it
would seem the developers are less than professional and put the 'release' in bad light. The
customers would remember there was a problem with delivery rather than the superior quality
of the product or the fact that we may have delivered on time or within budget.
• Production environments have unique characteristics that assist in making procedures more
robust and flexible:
• Assume that all data already in the database is to be kept. Any database changes or
reference/system data additions must be designed with this in mind.
• All migrations and changes are done with minimal downtime or disruption to the users of the
system.
• All changes should not compromise the integrity of the non-changed parts of the system or
the stability of other software/hardware on the same machines.
• Include processes and procedures for reversing out changes.
14
• Development activities should be performed in a minimum number of environments.

• Reduce the amount of junk existing in the environment. For example, one off programs used
by the programmer to debug something or dummy database files.
• The availability requirements for a production system are usually quite high and there is no
reason why other environment should not have similar requirements during high activity. Just
as a customer would not appreciate a productions system down at a critical moment you
would not want, say a development environment, down when you are at a critical stage in the
programming.
Management tasks are no different

During the planning, design and execution of any project activity, managers will use goals and
objectives to drive the project, have a management plan which they follow and use to manage the
activities, manage issues with developers and customers and manage risks on a day to day basis.
Configuration Management is no different. The techniques that any manager uses would apply to the
Configuration Management discipline but would only vary slightly to compensate for the type of work
that Configuration Management demands.
Remember Configuration Management produces output and output needs to be managed to be
successful. Of course with any project, the amount of formalized management will vary with the size
and complexity of the project.
To this end a Configuration Manager should be appointed to manage the Configuration Management
aspects of the project.
Begin with the end in mind

The main focus of delivery management is to deliver successfully. Firmly focusing on this when
conducting delivery management activities will make sure all the procedures are moving the project in
the right direction.
Assume an environment for change

Change is both inevitable and constant. As with any procedure or process in any development project,
refinements and changes in circumstances tend to result in ‘corrections’ and updates. Configuration
Management is no different. In fact Configuration Management is all about change, managing change
and implement change. Procedures and processes in Configuration Management should be both easily
adaptable to and robust to change.
All procedures and processes should be designed with change in mind and also executed with change
in mind.
Minimize the number of environments
15
The number of environments to use should be minimized. Adding extra environments adds extra
effort to maintain and they keep up to date. If there is a requirement for an inordinate number of
environments, you might want to charge extra per new environment. This would make the requestor of
the new environment examine the need rather than the convenience.
In one real life situation, one customer insisted in having multiple testing environments to simulate
differing time periods. After examining the requirement rather the need for extra environments, it was
found that other alternatives could be found such as changing the system time (logically not physically)
or restructuring the data to satisfy the requirement. The need to have the multiple environments was
eliminated but the requirement was satisfied.
Keep the solution simple as possible

For projects that are simple in nature the Delivery Management solution should be simple. For projects
that are complex there is no reason why the solution should also not be simple. Ensure that any
solution used for Software Configuration Management at your site can be maintained by the available
staff.
Automate where possible and necessary

Recently Software Configuration Management tools have come into the market that automates most of
the processes outlined in this whitepaper. These tools allow for basic and advanced delivery
management solutions to be employed and release the manager from mundane manual tasks to
concentrate on the delivery to the customer. If also fosters higher reliability.
Don’t release unless documentation is complete

Do not release to any environment until all documentation, whether it is related to Delivery
Management or not, is complete and in line with what you are releasing. Gone are the days where
documentation was written retrospectively several weeks, months or years after it has been released.
The advantages of updating your documentation are obvious but need to be discussed:
• Other implementations may want to reuse your code and need documentation to understand
and customize it for their needs. If there is no up to date documentation this greatly reduces
the likelihood of documentation.
• End Users are more likely to ask for complete documentation.
Do not assume a tool is a silver bullet

Do not assume that buying a Configuration Management Tool will solve all your problems. They
automate most of the processes but they are no replacement for the checks and balances (i.e. decisions
and sign off in formal change control and organization responsibilities) that is best served by human
interaction.
16
Tool vendors do not assist at all as they promote the tools as full lifecycle and solving all problems
(including world hunger…). They also typically will try to sell generic processes with the tool to
illustrate the full lifecycle or total solution aspect of the tool. Typically the processes are basic and are
applicable as a starting point for the final processes, but do not cover the management aspects of
anything but basic projects. They are promoted as the Software Configuration silver bullet.
This series has purposely steered away from discussing tools to any detail for the above reason and the
fact that the facilities available in tools in constantly changing.
Other Resources
This series is not the only source of information about Configuration Management. If you are
interested in further references the following web sites and books are recommended to be queried.
Web Pages
The following web pages may be worth referencing:
• Configuration Management Yellow Pages -
http://www.cs.colourado.edu/users/andre/configuration_management.html
• Configuration Management Resource Guide - comp.software-config-mgmt Frequently Asked
Questions.
Suggested External Reading

The following external papers and books may be worth considering:
• IEEE STD 610.12-1990, "IEEE Standard Glossary of Software Engineering Terminology."
• "AntiPatterns and Patterns in Software Configuration Management", William J. Brown, Hays
W. "Skip" McCormick III, Scott W. Thomas, Wiley Publishing, ISBN 0-471-32929-0,
Published 1999 – An excellent book for any project.
17
Concepts - Software Configuration Copyright © 2007-2013, Oracle and/or its affiliates. All rights reserved. This document is provided for information purposes only and
Management the contents hereof are subject to change without notice. This document is not warranted to be error-free, nor subject to any other
June 2013 warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or
Author: Anthony Shorten, Principal Product fitness for a particular purpose. We specifically disclaim any liability with respect to this document and no contractual obligations are
Manager formed either directly or indirectly by this document. This document may not be reproduced or transmitted in any form or by any
means, electronic or mechanical, for any purpose, without our prior written permission.
Oracle Corporation
World Headquarters Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.
500 Oracle Parkway
Redwood Shores, CA 94065 AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices.
U.S.A. Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license
and are trademarks or registered trademarks of SPARC International, Inc. UNIX is a registered trademark licensed through X/Open
Worldwide Inquiries:
Company, Ltd. 1010
Phone: +1.650.506.7000
Fax: +1.650.506.7200
oracle.com

Software Configuration Management - Concepts

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Software Configuration Management - Concepts

Transféré par

Droits d'auteur :

Formats disponibles

An Oracle White Paper

Concepts - Software Configuration

Conventions used in this whitepaper

What Is Configuration Management?

Figure 1 – The implementation puzzle

This representation is apt for a few reasons:

What Is Involved In Configuration Management?

Change Defect Status

Figure 2 – Component parts of Software Configuration Management

configuration items. This aspect of Configuration Management is covered in the Defect

Why is Configuration Management so important?

How to Read this series

ORDER DOCUMENT MANAGERS CONFIGURATION OTHERS

ORDER DOCUMENT MANAGERS CONFIGURATION OTHERS

9 Implementing Single Fixes ■ ■

10 Implementing Service Packs ■ ■

Configuration Management Concepts

AREA CONFIGURATION ITEM COMMENTS

AREA CONFIGURATION ITEM COMMENTS

Base Background Processes A set of precompiled background processes. Additionally

Other Base Documentation This is a set of MS word documents and online

AREA CONFIGURATION ITEM COMMENTS

CONFIGURATION ITEM COMMENTS

Operating System Used to house the product upon

Java Runtime Used to run the product

AREA CONFIGURATION ITEM COMMENTS

AREA CONFIGURATION ITEM COMMENTS

• Customization Baseline – This baseline is associated with the customizations implemented

PRODUCT BASELINE AUTOMATIC BASELINES CUSTOMIZATION BASELINE AUTOMATIC BASELINES

Mandatory Rollup or upgrade Major releases of customizations to customer

Upgrade of version of database or operating system as this

Configuration Management Approach

Guidelines For Effective Configuration Management

Treat each environment like a production environment

• Development activities should be performed in a minimum number of environments.

Management tasks are no different

Begin with the end in mind

Assume an environment for change

Minimize the number of environments

Keep the solution simple as possible

Automate where possible and necessary

Don’t release unless documentation is complete

Do not assume a tool is a silver bullet

Suggested External Reading

Vous aimerez peut-être aussi