2 Roadmap for Continuous Integration

Oracle Fusion Middleware 12c introduces new capabilities for build automation and continuous integration. Continuous integration is both a journey and a destination. If you have not automated your build process before, then you may find yourself at the beginning of the journey.

This chapter provides a roadmap to help you to understand the steps you need to take to attain continuous integration.

If you are familiar with build automation or continuous integration already, this chapter provides a summary of the features provided in Oracle Fusion Middleware 12c and helps you relate it to your existing experiences.

This chapter also describes a reference continuous integration environment. This is provided as an example to help you to visualize what your environment may look like after adopting the continuous integration approach and the tools and technologies described in this book.


Roadmap to Continuous Integration

When you use continuous integration, you follow a well-defined series of steps.

Table 2-1 describes the common steps that you must take to implement continuous integration, and also provides pointers for more information in each step.

Table 2-1 Roadmap to Attain Continuous Integration

Step Task See:


Implement a version control strategy

Installing and Configuring Subversion for Version Control provides details on how to set up a version control environment using Subversion.

If you are not currently using version control in your development environment, pay particular attention to repository layout, the Subversion workflow, and tagging and branching, which are described in Installing and Configuring Subversion for Version Control.

For more information about Version Control with Subversion, see:



Implement a binary repository strategy

Installing and Configuring the Archiva Maven Repository Manager provides details on how to use Apache Archiva to set up a repository for binary artifacts, both those that you are building and those that your builds depend on. Pay particular attention to understanding the need for multiple repositories, understanding the difference between snapshot and other repositories, and the administration and maintenance required for repositories.


Implement a build automation and dependency management strategy

Installing and Configuring Maven for Build Automation and Dependency Management provides a brief introduction to Maven and the installation and configuration steps. If you have never used Maven before, read material about it to get familiar with it. Start by reading "What is Maven?" at the official Maven web site at:


There are also a number of resources available online, including:

These resources can help you to form a comprehensive understanding on how to use Maven, some of the principles behind its design, and the kind of things you can do with Maven.


Populate your repository with Oracle artifacts

Populating the Maven Repository Manager provides details on how to populate your Maven Repository with Oracle-provided artifacts. Pay particular attention to understanding the Oracle Maven Synchronization plug-in, what happens when you apply patches to your Oracle runtime environments, the implications of patching on your build environment, and understanding the role of archetypes.


Ensure that you understand Maven version numbers

About Maven Version Numbers provides details on the important nuances of Maven version numbers. Ensure that you understand how to use Maven version numbers and version number ranges to specify dependencies, and how Maven resolves dependencies based on the way you specify version numbers.


Learn how to build Java EE applications for WebLogic Server using Maven

Building Java EE Projects for WebLogic Server with Maven provides details on how to create Java EE applications using the Oracle WebLogic Maven archetypes, and how to compile, package, and deploy your applications to a WebLogic Server.


Learn how to build Coherence applications using Maven

Building Oracle Coherence Projects with Maven provides details on how to create Coherence GAR applications using the Oracle Coherence Maven archetypes, and how to compile, package, and deploy your applications to the Coherence container on WebLogic Server.


Learn how to build other types of applications using Maven

For information on building other types of applications using Maven, see:


Learn how to build a whole application using Maven

Building a Real Application with Maven describes how to bring together many of these concepts to build a more realistic application. The example application has multiple component parts, each targeted to a different Oracle Fusion Middleware runtime environment. It also has dependencies between components, and some custom packaging requirements.


Learn how to customize your build process using Maven POM inheritance

Customizing the Build Process with Maven POM Inheritance provides details on the Maven POM hierarchy that is included with Oracle Fusion Middleware 12c. The common Oracle parent POMs provide an easy way to customize your build process.


Implement a continuous integration strategy

Installing and Configuring Hudson for Continuous Integration describes how to set up Hudson to create an environment in which to perform continuous integration. From Build Automation to Continuous Integration expands on this with details of the important considerations for establishing and operating a continuous integration environment.

Overview of the Reference Continuous Integration Environment

This guide uses a specific reference implementation of a continuous integration environment based on Subversion, Maven, Hudson, and Archiva.

Figure 2-1 provides an overview of the recommended development environment.

Figure 2-1 Reference Continuous Integration Environment Architecture

Description of Figure 2-1 follows
Description of "Figure 2-1 Reference Continuous Integration Environment Architecture"

The following is a description of the environment:

  • Maven's Central Repository and Oracle Maven Repository: These are external Maven repositories that hold open source and Oracle dependencies, which you may need for a build. The Maven Repository Manager is able to search these repositories for any dependencies that it does not have in its own repository, and obtain them if they are available.

  • The Maven Repository Manager: The repository for all built artifacts and dependencies, both for those created in your environment and those from external sources. Typically, there are different repositories for different purposes:

    • The Binary Repository Manager acts as a mirror or proxy for external Maven repositories like Maven's central repository and the Oracle Maven Repository. When artifacts from these repositories are needed for a build, they are downloaded and stored in a repository managed by the Maven Repository Manager.

    • When you build an artifact (for example, a WAR, JAR, or SAR file), it is published into a repository managed by the Maven Repository Manager. Often there are separate repositories for SNAPSHOT (work in progress) artifacts and release (final) artifacts.

  • The Subversion server: The repository for source artifacts that are created by your developers. Typically, there are multiple repositories. For example, there may be one per project.

  • The Hudson continuous integration (master) server: The server that manages your continuous integration builds. It is responsible for running builds and collecting and reporting results of those builds.

  • Hudson slave servers: Optional additional Hudson servers that are used to provide additional capacity. If you are running a large number of builds, you can set up several Hudson slave servers to share or perform some of the builds.

  • File server: A storage area network (SAN) or network-attached storage (NAS) that hosts copies of any product binaries that are needed by the Hudson build servers. For example, ojdeploy is required to build Oracle ADF applications. All of the Hudson servers have access to this file server.

  • Test servers (not shown): If you are performing integration tests, you may also have a set of test servers in which you deploy built artifacts like WARs, JARs, and SARs, and execute your integration tests.

  • The developer's machine: Each developer has a workstation on which to run an integrated development environment (Oracle JDeveloper) to create source artifacts like Java code, deployment descriptors, BPEL processes, and ADF user interface projects. JDeveloper includes a Subversion client. This enables the developer to perform actions like checking code in and out of repositories on the Subversion server, checking differences, performing merges, and resolving conflicts. Each developer's machine also has a local Maven repository on their workstation, which holds dependencies that are needed to perform local builds that they may want to perform on their workstation. For example, a developer might want to check a build and run unit tests locally before checking in code to the shared Subversion server.

Depending on the size of your environment, these components (excluding the external ones and the developer's machine), might be on a single server, or spread across several machines.

Shared Disk Layout

You can use a shared disk in a continuous integration environment, but you should use a well-thought out directory structure.

If you plan to use a shared disk, consider keeping all of your Subversion, Maven, Hudson data, and product binaries on the shared disk.

Figure 2-2 shows a suggested directory structure. This structure shows only the high-level directories that you would consciously consider creating.

Figure 2-2 Directory Structure for a Shared Disk

Description of Figure 2-2 follows
Description of "Figure 2-2 Directory Structure for a Shared Disk"

Note that for the product binaries, you must keep one copy for each environment (such as production, development, and QA). Although the product binaries are on the same version of the software, they are likely to have different patches installed. Ensure that you can always build using the same set of artifacts, possibly patched, as the environment to which you want to deploy.

Although you may have moved your development environment to 12.1.3 in the example in Figure 2-2, you still must to be able to build against 12.1.2. If you find a bug in production or QA, you must be able to build using the same versions of artifacts as you have installed in those environments.

Your Maven Repository Manager, Archiva in this case, includes the following repositories:

  • Internal: Stores finished artifacts that you have built in your development environment.

  • Snapshot: Stores work-in-progress artifacts that you have built in your development environment.

  • Mirror: Stores dependencies that have been downloaded from an external repository.

  • Dev, test, qa, prod: You have one repository for storing the dependencies needed for each target environment. You do this because it is possible that two environments might have the same version of an artifact (for example, 12.1.3-0-0) even though the artifact has been patched in one environment, and is therefore different. See Things to Know About Patching to learn more about this requirement.

The shared disk server must provide sufficient space for product binaries, Subversion repositories, the Archiva repository, Maven binaries, Hudson binaries, configuration, and file storage. At a minimum, Oracle recommends that you allocate at least 40 gigabytes. Factors, such as Archiva snapshot clean up rules and whether or not you permit check-in of binaries into the source control system, can increase the required space.