In the final blog article in the FlexDeploy Loves E-Business Suite series I will incorporate Continuous Integration and Automated Testing, enabling DevOps at a powerful scale. Incorporating the key elements of DevOps enables rapid and high-quality software delivery to customers, placing more focus on IT’s greatest value – innovation!
- FlexDeploy Loves Oracle E-Business Suite: Series Overview
- DevOps Best Practices for Oracle EBS
- FlexDeploy Loves Oracle E-Business Suite: Crawling
- FlexDeploy Loves Oracle E-Business Suite: Walking
- FlexDeploy Loves Oracle E-Business Suite: Running!
In the previous blog article, I defined a pipeline to enable continuous delivery of E-Business Suite packages. That alone is very powerful, replacing manual steps with automated ones and creating a streamlined orchestration to enable rapid delivery. However, there are still a couple of choke points, especially with shorter release cycles. To make the point, consider a mature continuous delivery pipeline where dozens of changes are delivered to production every week. Put on your running shoes and follow me!
There are three bottlenecks in the pipeline which can be improved.
- Creating packages, adding any modified files to them, and then adding these packages to the release
- Initiating builds whenever the files in the release packages change
- Ensuring quality of the release (i.e. testing)
Managing Packages
It’s very common for mid to large sized EBS implementations to have thousands of customizations across several EBS Modules. EBS development teams can be sized anywhere from a handful to 100+. With rapid delivery teams can end up creating and managing many packages concurrently. With a proper SCM branching strategy there is an easier way.
In the previous blog I created a few packages and placed them into the release. I then added a few files to each of these packages, kicked off builds, and sent them to the pipeline for execution. FlexDeploy also has the means to initiate the build for all files in a stream/branch, without having to create a package at all.
Wait a minute, why would I want to build and deploy all files? Keep in mind that I said build all files, not deploy all files.
At build time, FlexDeploy will gather the latest revisions from source control and assemble them into a build artifact. At deployment time, since FlexDeploy is managing the deployment of every file, it knows whether the existing revision is already present in the environment or not. You may have hundreds or thousands of files in the build, but everything will be skipped except the files which have changed. In other words, you are delegating the determination of which files need to be deployed to FlexDeploy.
In order to make this a reality, you will need to have separate source control branches for each release. This is the widely followed practice with Git, but the same principles can be followed with any source control system. FlexDeploy aside, having dedicated branches for your release will remove the error-prone step of ensuring that the proper revisions are moved to the right place. All SCMs have tools for branching and merging.
The configuration in FlexDeploy is defined in three simple steps:
Step 1 – Create a stream for the project(s) being modified for the release.
Step 2 – Add the project to the release, selecting the stream, and indicating that “All Files” will be used.
Step 3 – When submitting the build request for the release, select “All Files” instead of “Select Files”, as we did in the previous blog.
Continuous Integration
Ok, now we are working up a pretty good sweat! If FlexDeploy is building all files, and deploying everything which has changed, then why do I need to submit a build and deployment request at all? Good question. That takes us to the next topic, Continuous Integration.
With Continuous Integration, the goal is to integrate and test changes early and often. As such, FlexDeploy can be configured to listen for changes in a branch and initiate a build when any changes occur. If the configuration associates the build to a release, a snapshot will be created at the conclusion of that build, and will be sent to the pipeline for execution. The developer commits a change and FlexDeploy performs the build and kicks off the pipeline execution, orchestrating the process which you defined.
To configure continuous integration for your project, it’s as simple as adding a Poll SCM Trigger for the project.
Automated Testing
Have you ever looked at a project plan which has a few weeks of development time, and a few months for testing and other release related activities, and just shook your head? If it makes you feel better, you are not even close to alone. It’s one of the major contributing factors on why delivering software can be so expensive. It’s also one of the biggest barriers to frequent delivery. If it takes weeks or months to test, then you simply can’t deliver any faster than that. Rapid delivery is no good to anyone if the quality suffers as an unintended consequence.
One of the core tenants of Continuous Integration is automated testing. If you integrate frequently with the purpose of finding issues early, unless you have an army of people, it’s nearly impossible to scale without automated testing. Finding the issues faster generally makes it faster to resolve them, since changes are isolated and can be easily tracked to the offending source code. Finding issues early also makes the resolution cycles faster, since the associated change is top of mind for the developer.
FlexDeploy has integration with many popular test tools such as JUnit, SOAP UI, Postman, Oracle ATS, and HP UFT to name a few. The integration provides connection to these testing platforms and execution of defined tests. The results are then pulled into FlexDeploy, where decisions can be made within your workflows and pipelines.
As an example, I have created a connection in the Topology to Oracle ATS running on a Windows VM in the Oracle Cloud.
On my XXAP project, I have created a reference to the particular tests by defining a Test Definition and placing it into a Test Set for “smoke testing”.
I then defined a testing strategy for the smoke tests to be executed in each of my three environments for the EBS instance.
In my pipeline, in each stage after the deployment step, I have included a test step to execute all smoke tests for the projects in the release within the stage/environment. In the gates of the next stage, I have created a Test Gate to verify that the test results have passed. Although not shown in the configuration of the tests, it should be noted that you can define what it means to “pass” or “fail” based on number of failed test cases or percentages of failures.
In Action
Now let’s piece it all together by committing a change to the SCM branch for the XXAP project.
Within the configured interval set for the trigger I see a build request executing, and it is associated with my April Release.
Upon completion of the build, a new snapshot is created and sent to the pipeline for execution. The deployment in Test has completed, and the smoke tests have been executed.
Drilling down into the deployment details, I can see that all files have been skipped, except for the one which I made the source code change for.
I can also see the change logs showing which commits were processed.
On the Tests Results tab, I can see the test cases which were executed and that they all passed.
Deep breath, all finished!
Summary
The pressure on IT to innovate and keep up with technology and the never-ending business demands have never been higher. IT is often treated as a cost center, rather than the revered partner that it should be. As IT professionals we understand the demand from our customers. We also face challenges internally with the rigor that goes into ensuring quality, high performance, and generally accepted release management practices. This overhead has made it challenging to keep up, and has many times led to soured relationships between IT and the business/customer. The adoption of DevOps and CI/CD have opened the doors to a new path forward.
Previous Post: FlexDeploy Loves Oracle E-Business Suite: Walking
