Topics:
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.
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.
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 |
|---|---|
|
|
Ensure that the project is correct and all necessary information is available. |
|
|
Compile the source of the project. |
|
|
Test the compiled source code using a suitable unit testing framework; tests should not require the code to be packaged or deployed. |
|
|
Take the compiled code and package it in its distributable format, such as a JAR, WAR, EAR, SAR, or GAR files. |
|
|
Process and deploy the package, if necessary, into an environment where integration tests can be run. |
|
|
Run checks to verify whether the package is valid and meets quality criteria. |
|
|
Install the package into the local repository for use as a dependency in other projects locally. |
|
|
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.
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
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.
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.
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.