1 Introduction to Continuous Integration

Continuous integration involves applying small and frequent quality control efforts, and automated builds, deployment, and testing. Together with a set of tools, you can create a continuous integration environment in the context of Oracle Fusion Middleware.

Topics:

• Introducing Continuous Integration for Oracle Fusion Middleware
  When enterprises develop applications to support their business needs, they typically employ teams of developers who work together, often in small teams, with each team building a part of the application. These parts are then assembled to create the whole application. To improve quality and reduce the time to deliver software, apply small and frequent quality control efforts, and automated builds, deployment, and testing. This is known as continuous integration.
• Version Control with Subversion
  Subversion is a popular version control system. It was originally created as a logical successor to the Concurrent Versioning System (CVS), which is still widely used today. It works well in various network environments.
• Build Automation and Dependency Management with Maven
  Maven is a project management and build management system and is based on the central concept of a build life cycle. The process for building and distributing a particular artifact or project is clearly defined.
• About the Oracle Maven Repository
  The Oracle Maven Repository contains artifacts provided by Oracle that you may require to compile, test, package, perform integration testing, or deploy reapplications.
• Repository Management with Archiva
  When several developers are working on a project, enterprises often find it useful to establish their own internal Maven repository and to manage it with a Maven Repository Manager, such as Apache Archiva.
• Continuous Integration with Hudson
  Hudson is a common continuous integration server product that enables you to automate the build process.
• Summary
  This guide describes how to establish a continuous integration environment that supports a large team of developers who develop applications on the Oracle Fusion Middleware 12c platform.

Introducing Continuous Integration for Oracle Fusion Middleware

When enterprises develop applications to support their business needs, they typically employ teams of developers who work together, often in small teams, with each team building a part of the application. These parts are then assembled to create the whole application. To improve quality and reduce the time to deliver software, apply small and frequent quality control efforts, and automated builds, deployment, and testing. This is known as continuous integration.

Many modern applications are based on a service-oriented architecture (SOA). This means that developers build services (small pieces of business functionality) that can be assembled in various ways to meet the needs of the business application. Some of the features of SOA that make it popular today are:

• Loose coupling of components of the application, which reduces the impact of change

• Reuse of services, a long time goal of Information Technology development

• The flexibility and agility to easily change the application's behavior as the business need changes

In this new paradigm, many development organizations are also adopting iterative development methodologies to replace the older waterfall-style methodologies. Iterative, agile development methodologies focus on delivering smaller increments of functionality more often than traditional waterfall approaches. Proponents of the new approach claim that the impact is usually less for errors that are found sooner and that the approach is especially suitable to today's environment of constant and rapid change in business requirements.

Many of these techniques also feature the adoption of continuous integration. Organizations have a strong interest in automating their software builds and testing, and continuous integration can help accomplish this.

Continuous integration is a software engineering practice that attempts to improve quality and reduce the time taken to deliver software by applying small and frequent quality control efforts. It is characterized by these key practices:

• A version control system is used to track changes.

• All developers commit to the main code line, head and trunk, every day.

• The product is built on every commit operation.

• The build must be automated and fast.

• There is automated deployment to a production-like environment.

• Automated testing is enabled.

• Results of all builds are published, so that everyone can see if anyone breaks a build.

• Deliverables are easily available for developers, testers, and other stakeholders.

Oracle Fusion Middleware 12c provides support for enterprises that adopt continuous integration techniques to develop applications on the Oracle Fusion Middleware platform. Specifically, it provides the following:

• Integration with common version control systems from the development tool, Oracle JDeveloper

• The ability to build projects from the command line using Maven, a build and project management system, so that the build can be scripted and automated

• The ability to create new projects from Maven archetypes

• The ability to download necessary dependencies from the Oracle Maven Repository, and other Maven repositories

• The ability to parameterize projects so that builds can be targeted to different environments, such as Test, QA, SIT, and production

• The ability to include testing of projects in the Maven build life cycle

• The ability to populate a Maven repository with Oracle-provided dependencies from an existing local Oracle home software installation directory

• The ability to run Maven builds under the control of a continuous integration server like Hudson

• Comprehensive documentation about setting up your build or continuous integration environment, or both, to use with Oracle Fusion Middleware

Choices are available for version control, continuous integration, and other components that enterprises typically use in this kind of environment. Many of these components are free and open source, and others are commercial products. This guide presents a reference environment based on the following set of components:

• Apache Subversion for version control

• Apache Maven for build or project management

• Apache Archiva as the Maven repository manager

• Apache Hudson as the continuous integration server

Note that these are not the only choices available. You can use, for example, a different version control system or a different continuous integration server. For most common alternatives, you should be able to adapt the examples in this guide without much difficulty.

Version Control with Subversion

Subversion is a popular version control system. It was originally created as a logical successor to the Concurrent Versioning System (CVS), which is still widely used today. It works well in various network environments.

Subversion is used as the version control system in the examples in this guide for the following reasons:

• It is well integrated with Oracle JDeveloper, the development tool that is most commonly used to build applications for the Oracle Fusion Middleware platform and with other common development tools.

• It works well in various network environments, including virtual private networks and HTTP proxies. Thus, it is well suited for the kind of network environments often encountered in enterprises and their partners, and suppliers.

• It supports various authentication options, including strong authentication with certificates.

• For projects using Oracle SOA Suite, it provides an atomic commit that enables developers to update several files as part of a single check-in or commit operation.

A typical Subversion environment consists of one or more Subversion repositories that store source code artifacts. These are accessed by developers using Subversion clients, either included in their integrated development environments or as standalone clients. Developers can copy artifacts to and from the repositories. When a developer changes an artifact, a new version of the artifact is created in the repository. Developers can view and compare versions of artifacts to see what was changed and who changed it.

Build Automation and Dependency Management with Maven

Maven is a project management and build management system and is based on the central concept of a build life cycle. The process for building and distributing a particular artifact or project is clearly defined.

Maven provides project management in terms of:

• Naming and version numbering

• Dependencies

• Where the source code is stored

• Where builds are stored

• Templates for project types

• The release process

Maven provides build management in terms of:

• How to execute the build

• What to do in each phase

• Parameterization of the build

• An extensible framework

For developers to use Maven, they must learn a small set of commands that enable them to build any Maven project. The Maven Project Object Model (POM) ensures that the project is built correctly.

There are three main life cycles defined:

• Default: To build the project

• Clean: To remove all generated artifacts from the project

• Site: To build documentation for the project

Build life cycles are further defined by a set of build phases. A build phase represents a stage in the life cycle. Build phases are executed sequentially to complete the life cycle. Build phases consist of goals that perform the actual tasks. There is a default set of goal bindings for standard lifecycle phases. Maven plug-ins contribute additional goals to a project. The following table shows the build phase and purpose of each phase:

Table 1-1 Maven Build Phases

Build Phase	Purpose
validate	Ensure that the project is correct and all necessary information is available.
compile	Compile the source of the project.
test	Test the compiled source code using a suitable unit testing framework; tests should not require the code to be packaged or deployed.
package	Take the compiled code and package it in its distributable format, such as a JAR, WAR, EAR, SAR, or GAR files.
integration-test	Process and deploy the package, if necessary, into an environment where integration tests can be run.
verify	Run checks to verify whether the package is valid and meets quality criteria.
install	Install the package into the local repository for use as a dependency in other projects locally.
deploy	For the final release, copy the final package to a remote repository for sharing with other developers and projects.

A typical Maven environment consists of a Maven installation on each developer's local machine, a shared Maven repository manager within the enterprise, and one or more public Maven repositories where dependencies are stored. The main Maven repository is known as Maven's central repository. This repository stores many free and open source libraries that are commonly used as dependencies during development projects. Examples include the JUnit unit testing framework; Spring, Struts, and other common user interface libraries; and code coverage and style-checking libraries like Cobertura and PMD.

About the Oracle Maven Repository

The Oracle Maven Repository contains artifacts provided by Oracle that you may require to compile, test, package, perform integration testing, or deploy reapplications.

Specifically, the Oracle Maven Repository contains the following:

• Client API classes

• Compilation, packaging, and deployment utilities, for example, wlst

• Component JARs that must be embedded in the application

• Client-side runtime classes, for example, t3 and JAX-WS client runtimes

Repository Management with Archiva

When several developers are working on a project, enterprises often find it useful to establish their own internal Maven repository and to manage it with a Maven Repository Manager, such as Apache Archiva.

Consider establishing your own internal Maven repository to:

• To act as a proxy or cache for external Binary repositories, like Maven's central repository or the Oracle Maven Repository, so that dependencies are downloaded only once and cached locally so that all developers can use them.

• To store artifacts that are built by the developers so that they can be shared with other developers or projects.

Although a Maven repository can be as simple as a file system in a particular layout (directory structure), most organizations find that it is more convenient to use a type of software called a Maven repository manager. This helps in addressing the purposes previously listed. In this guide, Apache Archiva is used as the Maven Repository Manager. Others are available, either for free and commercially.

In a typical enterprise that use Archiva, Archiva is set up on a server that is accessible to developers and build machines. The enterprise defines the following repositories on this server:

• A mirror of Maven's central repository

• An internal repository to store internally developed artifacts that are completed or published

• A snapshot repository to store internally developed artifacts that are under development and not completed yet

There can also be additional repositories depending on the need. For example, there can be additional repositories for particular projects, or for different versions of dependencies needed for different life cycle stages. For example, bug fix to production might use different dependencies from the current version under development.

All developers must configure Maven installations to point to these internal repositories instead of the external repositories, so that developers can use artifacts already stored in the internal repositories and reduce the download and build time. This also helps to ensure that all developers use the same version for various dependencies.

Archiva also provides the ability to manage the expiration of artifacts from your snapshot repository. Each time that you execute a build, artifacts are created and stored in the snapshot repository. If you are using continuous integration, you may want to execute builds several times each day. The best practice is to configure Archiva to remove these stored artifacts after a certain amount of time (for example, one week). Alternatively, you can configure Archiva to keep just the last n versions of each artifact. Either approach helps to automatically manage the expiration and deletion of your snapshot artifacts.

Continuous Integration with Hudson

Hudson is a common continuous integration server product that enables you to automate the build process.

Typically, this automation includes steps such as:

• Initiating a build whenever a developer commits to the version control system

• Checking out the code from the version control system

• Compiling the code

• Running unit tests and collating results (often through JUnit)

• Packaging the code into a deployment archive format

• Deploying the package to a runtime environment

• Running integration tests and collating results

• Triggering the build to the Maven snapshot repository

• Alerting developers through email of any problems

However, it is also possible to use the build system to enforce compliance with corporate standards and best practices. For example, enterprises can include the following steps in the build process:

• Running code coverage checks to ensure that an appropriate number of unit tests exist and are executed

• Running code quality checks to look for common problems

• Running checks to ensure compliance with naming conventions, namespaces, and so on

• Running checks to ensure that documentation is included in the code

• Running checks to ensure that the approved versions of dependencies are used and that no other dependencies are introduced without approval

Hudson provides a web-based console that enables build managers to define, execute, and monitor builds. Builds are executed on one or more build servers. The number of build servers is typically defined based on the volume of builds and the expected time for a build to complete. Hudson also provides APIs and can be extended through a plug-in mechanism, so that additional functionality can be added, as needed.

Summary

This guide describes how to establish a continuous integration environment that supports a large team of developers who develop applications on the Oracle Fusion Middleware 12c platform.

This environment includes version control, Maven for build automation and dependency management, Archiva as a Maven repository, and the use of a continuous integration server like Hudson to automate the build process.

All examples in this book use Apache tools: Subversion, Maven, Archiva, and Hudson. However, there are other commercial and open source alternatives that you can use. The intention here is to provide an example that you can refer to and that should be easy enough to adapt to other tools. For example, you may choose to use git for version control or Nexus as your repository manager. The choice of tools in this documentation does not imply that other tools will not deliver equivalent outcome.