Databases Reference
In-Depth Information
C H A P T E R 9
Lifecycle Management
by Dietmar Aust
Every application changes over time. Keeping track of different software versions in multiple
environments (development, test, and production) quickly becomes a nontrivial task which every
developer has to confront.
In this chapter we will detail best practices acquired from developing and maintaining multiple real-
world projects for customers over the years. These procedures have proven to be very effective and
reliable, significantly improving the quality of the delivered applications. They originated, for the most
part, from the experiences of our project team at the German Telecom Shops, where we developed and
maintained an APEX application over the last four years.
To successfully deliver high-quality software on time, we have learned that in a shared environment,
you should not focus solely on source code-related issues. You also need to answer questions related to
project management and documentation to support your daily activities and stay on track. To establish
procedures that work reliably even under pressure, we have learned to focus on the following:
•
Simplicity
: Implement only a few easy to follow rules (the KISS principle).
•
Transparency
: Establish clear and concise naming conventions, which helps to
implicitly document what you are doing.
•
Safety
: Implement a strict system of templates, checklists, and rules to follow so
that you will make fewer mistakes.
We have developed and continue to evolve procedures for requirements management, a proven
file-system layout, automated DDL extraction, a completely script-based deployment approach, and
integration with Subversion. All of these support the long-term maintainability of the software.
Interestingly enough, we couldn't find any established best practices for source code management
in the Oracle ecosystem; in the Java community, however, most people seem to have agreed on Apache
Maven (
http://maven.apache.org
). Apache Maven is a software tool for project management and build
automation which has established conventions on how to structure the file system for a project, naming
conventions for files, and how to do things in a project. It was born from the very practical desire to
make several projects at Apache work in the same way. The intent of the Maven project was to enable
developers to freely move between projects; by understanding how one of them worked, they would
understand how they all worked. If a developer spends time understanding how one project is built, they
should not have to go through the same process again on the next project. The same idea extends to
testing, generating documentation, generating metrics and reports, testing, and deploying.
