As each industry becomes more tightly integrated into the digital economy, each organisation is becoming a technology company (often by stealth). In this world, the speed at which organisations can reliably deliver software solutions is becoming a key market differentiation.
Companies that incorporate DevOps practices get more done, according to the Puppet Labs 2015 State of DevOps survey;
High-performing IT organizations experience 60 times fewer failures and recover from failure 168 times faster than their lower-performing peers. They also deploy 30 times more frequently with 200 times shorter lead times.
One of the core tenants of DevOps is to automate everything. In this article we examine how we can automate the Build & Deployment of Oracle BPM and SOA solutions.
Automating the Software Deployment Pipeline
During the lifetime of a project, code will be built and promoted to various staging environments such as Development, System Integration and Test (SIT), User Acceptance and Test (UAT), Pre-Prod, and Production.
The overall goal of the deployment pipeline is to detect any changes that will lead to problems in production. At each stage in the deployment pipeline, different levels of testing will be applied. Early stage tests are targetted at being quick and simple to run, but should capture the majority of the problems, so providing fast feedback and allowing for quick cycle times.
Later stages in the delivery pipeline provide more comprehensive testing, some of which may be manual, or take longer to set-up and run; with each successive stage provides increasing confidence in the overall build quality.
Automating the deployment pipeline is the key requirement to enable continuous delivery. This process involves automating the building of the software, the deployment of each build into each staging environment, and the automation of tests conducted in each environment.
We also need to automate platform provisioning, to ensure that each build is deployed to, and tests carried out against, correctly configured and reproducible environments.
As well as automating each step in the process, we also need to automate the end to end orchestration of these steps; this will typically consist of a separate deployment pipeline for each staging environment, as well as a top-level view of the entire pipeline, allowing you to define and control the stages and gain insight into the overall software delivery process.
The pipeline starts by building the binaries to create the deliverables that will be passed to the subsequent stages. During this process, the CI Server will check out the latest committed version of the code from the source code repository into a temporary directory.
It will then invoke the necessary tasks to build and compile that code. For Oracle SOA, OSB, and BPM, the simplest way to achieve this to do a direct build with Rubicon Red MyST; this will automatically detect the type of source code artifacts and build them accordingly.
Alternatively, these tasks can be scripted using a tool such as Maven or Ant.
The output of this build is then packaged up as a release and placed into a software repository, such as Artifactory or Nexus, ready to be deployed into any of the staging environments.
With composite applications that leverage a number of disparate sources, it is a common anti-pattern to create a separate deployment unit, i.e. build, for each environment. With this approach, endpoint references are manually updated in the required configuration files before packaging up the deployment unit. This introduces the risk that endpoints are not updated correctly or that the output of a build can be deployed into the wrong environment.
Best practice is to have a common build, and automatically configure these environment-specific configurations as part of the deployment process.
Automated Deployment and Configuration of Oracle Middleware Code
The next step in our delivery pipeline is to deploy the latest release into the staging environment.
Rubicon Red MyST is the enabling technology that allows you to quickly establish a standardized, repeatable, and automated process for the deployment of Oracle Middleware solutions at each stage in the Software Delivery Pipeline. MyST shifts the experience from a resource intensive and highly error prone process to an automated, predictable, and low risk process that can be performed in a fraction of the time.
Release Blueprints are used to define the artifacts that constitute a release, the configuration requirements for these artifacts, and the configuration changes that will need to be applied to the Oracle Middleware Platform. These blueprints are version controlled, allowing us to treat configuration as code, ensuring strong governance and consistency across the release process.
The deployment fetches the output of the earlier build from the software repository. Before deploying the packaged code, any references it has to other artefacts, such as service endpoint locations, database connection details, and file locations, need to be configured for the target environment. These configurations are defined as part of the Release Blueprint, and automatically applied by MyST during the deployment process.
In addition to deploying the package to the target environment, configuration changes may need to be made to the Oracle Middleware Platform, such as the creation of data sources, JMS Queues, and other resources, as well as the application of patches. These changes are also defined as part of the Release Blueprint, and again automatically applied by MyST as part of the deployment process.
Continuous Delivery for Oracle BPM and SOA
The goal of continuous delivery is to help software development teams drive waste out of their process by simultaneously automating the process of software delivery and reducing the batch size of their work. This allows organizations to rapidly, reliably, and repeatedly deliver software enhancements faster, with less risk and less cost.
Applying Continuous Delivery in the development of Oracle Middleware projects can deliver significant reductions in development time and costs.
Download White Paper
In subsequent posts I will go into further details on testing approaches, as well as how to ensure that deployments are always to production-like environments. Click here download a white paper on Best Practice for Implementing Continuous Delivery for Oracle Middleware.