Databases Reference
In-Depth Information
Parallel Development (Branching and Merging)
Creating a hotfix for a current problem in the production environment is one typical case where parallel
development is required. You would implement a correction of the current production version while
developing the next release in the regular development environment. This typically requires a small
change to the production version.
The suggested approach for hotfixes has already been detailed. It involves making changes to a copy
of the production system on a separate APEX instance. Once the hotfix is tested and installed on the
production system, these small changes need to be manually integrated into the current stream of
development.
Another typical use case occurs at the end of a development cycle. Usually only some of the team
members do the bug fixing and the iterations with the test team, and the rest of the development team
will start to work on the next release.
How can that parallel development be supported? We recommend manual branching and merging
procedures. For example, as seen in Figure 9-8, the application version in the current development cycle
has the application ID
100
(application version
1.0.0.0
). If you want to branch the development to start
the development of new features in version
2.0.0.0
you simply create a copy and use the application ID
200
for the branched version. Perhaps you might even create a separate database schema
FM BRANCH
in
which you would install a copy of the current
1.0.0.0
release.
Then you make changes to version
1.0.0.0
and iterate to internal revisions
1.0.0.1
,
1.0.0.2
, and
1.0.0.3
for application ID
100
. At the same time the development of version
2.0.0.0
already started
using application ID
200
.
Figure 9-8.
Branching and merging
Typically, you would add new functionality in the next release, so it is fair to say that (for the most
part) you will add new pages to the application. Once version
1.0.0
has reached the final iteration
(
1.0.0.2
) and is installed in production, you can merge the branch with the main development again,
resulting in version
2.0.0.2
. Merging the sources for the database packages is supported by Subversion.
It provides tools for displaying differences as well as semi-automatically merging them into a
consolidated file. The new pages from the APEX branch (
2.0.0.1
) will have to be copied over manually
to the main version
1.0.0.2
.
You have to take care of one important aspect. Once you branch off your regular development
trunk, you have to make sure that you diligently preserve page ranges for each branch. This is really
important! Otherwise the manual merge procedure will be quite tedious because you could have page id
conflicts which you would have to resolve manually.
