In this blog article I will expand on the solution which was showcased in FlexDeploy Loves E-Business Suite: Crawling, and enable Continuous Delivery using FlexDeploy Pipelines and Releases. In the previous article I configured the workflows, topology, and project configuration, and performed basic adhoc build and deployments.
- 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!
While adhoc build and deployment automation by itself provides plenty of value, it leaves the coordination and orchestration activities to people. This can become a drain on resources, leaving us with the kind of latency that gets in the way of faster software delivery. Software development is an iterative process cycling over several environments, along with approvals, and other coordinated activities. Having an efficient orchestration of these activities is a key enabler to continuous delivery. So, let’s get up and start walking!
Pipelines
A FlexDeploy pipeline manages the orchestration of changes across the environments, and ultimately into production. A pipeline is made up of one or more stages (environments), and defines the order of propagation. For example, Test, then QA, then Production. Each stage is made of zero or more gates, and one or more steps. A gate defines a condition which must be met before proceeding to the steps (e.g. acquire an approval). A step defines an action to take while delivering changes to the stage (e.g. one or more deployments). Let’s look at a simple pipeline I created, called Erick’s Pipeline.
This pipeline has three stages, Test -> QA – > Production. The Test stage has no gates, which means it proceeds to the steps without any pre-condition. There is a single step in the Test stage, which performs the deployment(s) into the Test environment. The QA stage requires an approval from the QA Lead. Once the approval is acquired, the steps become eligible for execution. The steps in QA are the same as Test, with the only difference being the deployment target. The Production stage has two gates, an approval, and a scheduled gate which holds until some defined time. Once the approval is acquired and the scheduled time is reached, the Production steps become eligible for deployment.
A pipeline, like a workflow, is a reusable component which executes in context. The context here is what is called a release in FlexDeploy.
Releases
A FlexDeploy release represents a scope of work which is managed to a shared delivery milestone. This could be for a Monthly Release or a Hot Fix, for example. The scope of work can be as small or as large as appropriate. For example, let’s say we have a set of changes to deliver to the customer in March.
Here I have created a release called March Release, and bound it to use the Erick’s Pipeline we reviewed earlier. I have added three packages from the XXAP project as the content of the release. I then started the release so that it can be used to initiate changes across the defined pipeline.
Release Snapshots
When one of the projects or packages in the release is built, a new version of that project is produced. This project version is used to create what is call a snapshot. A snapshot is a collections of project versions representing builds for the release. The first build for a project/package will place it into a new snapshot. Every build produces a new snapshot, overlaying previous build version with the new version for that project/package.
In Action!
Let’s see it in action to gain a better understanding. Here I will create the first build for one of the packages in the release. Notice, because the XXAP project is now associated to a release, the release drop down appears on the build request form. I will select the March Release. The package drop down presents the list of packages in that release. Since this is the very first build for this package there are no files in it (it was created simply as a place holder). I will add a few files to this package and submit the request.
Since the build request is associated to a release, a snapshot has been automatically created once the build completes.
Notice on the project activity that after the build completes the deployment to Test has started. The pipeline is at work already.
Now I will switch over to the release dashboard for the March Release. Notice that a pipeline execution has been initiated for the pipeline associated to the release. The Snapshot Content reveals the packages and their versions which are in this snapshot. This is the version of the package that I just built.
Back on the execution screen we can see that, since there were no gates defined in Test, the execution immediately proceeds to the deployment step. After completion, execution transitions to the QA stage, and is awaiting an approval.
Now let’s return to the project and submit a build for one of the other packages in the release.
Once complete, a new snapshot is created and is sent to the pipeline for execution. Remember that the new snapshot is created by overlaying the new build version over top of the previous snapshot. On the release dashboard, we can see that there is now a second pipeline execution and the snapshot consists of two packages with the respective build versions.
I will now build the third package for the release.
Once completed, a third pipeline execution is initiated and the snapshot contents reveal versions for all three packages in the release.
Since there are no gates, the snapshots have all made their way through Test, and are awaiting deployment approval in QA.
Notice that all three snapshots contain version 1.0.1 of package XXAP-100, and the second two snapshots contain version 1.0.2 of package XXAP-101.
You may be thinking, “Why would I want to deploy the same version of the same package to Test multiple times?” That is a great question! FlexDeploy is aware of the versions of packages and files it deploys into each environment, and will skip deploying them if they are already present. If we drill into the deployment execution in test for the second snapshot we will see that it skipped the package for the version which was already deployed in the first snapshot.
Similarly, we can see in the third snapshot that the two previously deployed package versions were skipped.
By using FlexDeploy, organizations establish an automated and repeatable process for building, packaging, and safely deploying code, APIs, meta-data changes, and data migrations from development through test to production environments.
You may still be wondering why they are included if they are going to be skipped. They were skipped in Test, but now let’s approve the latest snapshot in QA. The gates are cleared and the snapshot proceeds to the steps, which includes deployment of the snapshot into QA. Here we see that all three of the packages deployed because they were never deployed there before.
So, what about the first two snapshots? Since a more recent snapshot for the release cleared the gates, any other snapshots waiting in the gates for the same stage are automatically terminated with an “Out of Date” status.
This approach avoids the situation where you need to approve/reject every singe snapshot. In the end, only one snapshot will make its way to production, completing the release. The snapshots being cumulative avoids any situation where you need to process all snapshots through the entire pipeline. Every release is iterative in nature, resulting in dozens or hundreds of snapshots, with many getting out dated because they are superseded with more changes.
Now the only running snapshot has completed deployment in QA and is pending approval in Production. If an issue is found, or more development occurs for the release, a new snapshot will be created and will ultimately come to production for approval. Now I will approve the snapshot in production, and see that it transitions to the scheduled gate.
Once the schedule is reached, the gates are cleared and the deployment to production occurs. Once the deployment is complete, the pipeline execution for the snapshot is now completed.
The same release could be used again for a warranty period or emergency changes supporting the release. If I end the release, no new snapshots can be created. A new release can be created, and the process starts over.
Summary
The advantages of using a release and pipeline in place of adhoc builds and deployments include:
- A defined model which represents the contents of a release
- Enforce that all changes progress through a defined process and set of environments
- Automate the orchestration of approvals and schedules
- Reduce the latency associated with requesting, waiting, and following up
- Visibility of the release execution and progression in the pipeline
- And more…
In the next and final blog article in this series I will show how the pipeline can be extended to kick things up yet another notch, implementing concepts such as continuous integration and test automation. We are close to achieving continuous delivery at powerful scale, but we are not quite there yet. Stay tuned!
Previous Post: FlexDeploy Loves Oracle E-Business Suite: Crawling
Next Post: FlexDeploy Loves Oracle E-Business Suite: Running!
