This is the eighth article in our series on what makes FlexDeploy a seamless fit for Oracle Fusion Middleware users. In this blog article I will walk through the core components of FlexDeploy, which enable the basics of build and deployment automation. I will demonstrate how to build and deploy SOA composites across any number of environments. In this blog article I will extend this SOA example using other functionality to enable an effective continuous delivery solution. All of these concepts apply to any FlexDeploy project type.
- FlexDeploy Loves Oracle Fusion Middleware: Overview
- FlexDeploy Loves Oracle Fusion Middleware: WebLogic Configuration Setup
- FlexDeploy Loves Oracle Fusion Middleware: MDS Setup
- FlexDeploy Loves Oracle Fusion Middleware: Service Bus Setup
- FlexDeploy Loves Oracle Fusion Middleware: SOA Setup
- FlexDeploy Loves Oracle Fusion Middleware: Continuous Integration and Issue Tracking
- FlexDeploy Loves Oracle Fusion Middleware: Test Automation
- FlexDeploy Loves Oracle Fusion Middleware: Release Pipelines
- FlexDeploy Loves Oracle Fusion Middleware: Integration with ServiceNow
In this post, I’ll discuss how FlexDeploy handles release pipelines and orchestration.
Software changes need to be deployed to a series of environments based on approvals, testing metrics and schedules. Release automation provides the ability to configure a release and pipeline to define how the deployments will occur. (See the FlexDeploy User Guide for more details.)
The projects that were used in the series are configured in the Blog release and will be executed through the configured pipeline. After we configure the projects in the release, we will update the ticket status in Jira. Let’s see how this will be setup in FlexDeploy along with how it executes.
Setup
We will need to create a pipeline that will define the environments involved in the deployment lifecycle along the orchestration gates and steps that control the execution. The release will be created and the projects will be added to define what will be deployed during execution.
Pipeline
The pipeline is a workflow that orchestrates the delivery of snapshots (a group of project and project versions to be deployed), across defined stages/environments which contain a series of gates and steps. Each gate blocks entry into the steps until all gate conditions are satisfied. The steps define the means of delivering the snapshot through the stage. Pipelines can be re-used with many releases.
With different project types being deployed at the same time, there can be a need to group projects together and have them deployed in an order. Utilizing Project Groups within a pipeline, we can provide user defined groups that will be utilized by the pipeline to define the deployment order and by the release to assign projects to these groups.
Looking at the Development stage of the pipeline, there are no configured gates, so the steps will automatically start executing. The stage is further configured with DeployAll steps in series based on the project group codes, this will provide deployment dependencies. Click on the expand arrows to edit the stage and the pipeline editor will open.
Now let’s look at the QA gates. There are two gates, Test and Schedule, that both need to be satisfied to continue execution in the QA environment. Click on the expand button to edit the stage and the pipeline editor will open. Click on appropriate gates and drag them from the palette to the gate section of the editor. The steps will be configured in the same manner as the Development stage. Make sure to activate the pipeline.
Release
Now that we have a configured pipeline, we can now create a release that is a collection of heterogeneous projects that will be deployed through the newly created pipeline. Configure each project with the appropriate project group code. Remember to start the release. Adding a Scheduled Build expression will activate continuous integration on each project configured in the release. The Poll SCM trigger that was added earlier can be removed now that we have added continuous integration through the release.
Execution
Now that we have a configured release with a pipeline, let see how the execution occurs. The release execution is started because the ValidateOrderProcess was changed and the continuous integration trigger that was previously setup detects and builds the composite. Upon a successful build of the composite, the Blog Release is executed with a new snapshot.
Since there are no gates in the Development Stage, the deployment of the process is already completed. With the QA stage configured with gates, the execution of the snapshot will be held until the conditions are met. With the successful execution of the testing in Development and the time matching the Scheduled gate, the deployment steps are executed. We can view the current snapshot execution by going to the Release screen and viewing the Release Dashboard for the Blog Release.
The Release Dashboard displays the current execution of the snapshot and provides the ability to drill into pipeline steps. The following list indicates several features that are depicted in the images below.
- Indicates that the first gate was completed and that all tests were successful.
- Indicates that the snapshot is waiting for the configured time to pass before allowing the snapshot to proceed. In this case, the time matched.
- Provides an override mechanism of the scheduled deployment time, if needed.
- Provides the capability of viewing what happened with the given step. Clicking on the step link will open the gate/step viewer. Then click on the Deploy All Services link to see the service execution and this will show that the ValidateOrderProcess was deployed and the CalculateInvoiceProcess was skipped since there were no changes.
Conclusion
Now we have configured FlexDeploy to detect changes, automatically build the project, initiate the release and deploy the project through the release.
The next and last post in this series will cover the utilization of an external approval gate, using ServiceNow, for the production stage.
