Fusion Middleware Documentation
Advanced Search


Developing Applications Using Continuous Integration
Close Window

Table of Contents

Show All | Collapse

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 with 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.

This chapter contains the following sections:

2.1 Roadmap

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

No. Task For More Information

1.

Implement a version control strategy

Chapter 3 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, then you should pay particular attention to repository layout, the Subversion workflow, and tagging and branching, which are described in Chapter 3.

For more information about Version Control with Subversion, see:

http://svnbook.red-bean.com

2.

Implement a binary repository strategy

Chapter 4 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. You should 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.

3.

Implement a build automation and dependency management strategy

Chapter 5 provides a brief introduction to Maven and the installation and configuration steps. If you have never used Maven before, you should do some reading to get familiar with it. Start by reading "What is Maven?" at the official Maven web site at:

http://maven.apache.org/what-is-maven.html

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

These resources will 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.

4.

Populate your repository with Oracle artifacts

Section 5.3 provides details on how to populate your Maven Repository with Oracle-provided artifacts. You should 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.

5.

Ensure that you understand Maven version numbers

Chapter 7 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.

6.

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

Chapter 9 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.

7.

Learn how to build Coherence applications using Maven

Chapter 10 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.

8.

Learn how to build a whole application using Maven

Chapter 11 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.

9.

Learn how to customize your build process using Maven POM inheritance

Chapter 8 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.

10.

Implement a continuous integration strategy

Chapter 6 describes how to set up Hudson to create an environment in which to perform continuous integration. Chapter 10 expands on this with details of the important considerations for establishing and operating a continuous integration environment.


2.2 Overview of the Reference Continuous Integration Environment

This chapter provides a 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. The dark blue components (shown in the middle) make up the shared (server) portion of the 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:

  • 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.

  • The Maven Repository Manager: This part of the development environment is the repository for all built artifacts and dependencies, both for those created in your environment and those sourced externally. 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. 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 (parent) server: The server that manages your continuous integration builds. It is responsible for running builds and collecting and reporting results of those builds.

  • Hudson child 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 child 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.

  • Maven's Central Repository: This is an external Maven repository that holds open source 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.

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.

2.3 Shared Disk Layout

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

A suggested directory structure is shown in Figure 2-2. 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, 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 up 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 Section 5.3.7 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.