This blog is the fifth in the FlexDeploy Loves OIC blog series, stay tuned for subsequent entries in the series.

Oracle Integration Cloud (OIC) provides the ability to develop an integration in the cloud.  The integration can connect cloud and/or on-premise applications; now that we have test automation setup along with Continuous Integration with OIC, it is time to bring this all together with Continuous Delivery through FlexDeploy’s release/pipeline capabilities.

I will walk you through setting up our OIC project in a release that provides software delivery of a collection of projects to enable new functionality to the user.  We will also utilize a pipeline component with the release that orchestrates the continuous delivery of projects across environments.

FlexDeploy Configuration

We will start by creating a pipeline that will be configured to execute gates and steps across multiple environments.  Select the Pipeline page and then click on the Create button.

Now we can name the pipeline so that we can setup a couple of administrative components of the pipeline.  We need to have an approval group that will be used when we add an approval gate to the pipeline.  Click on the Team tab and click on the plus button in the upper-right corner of the page.  I shuttled the FD Administrators group to the left box.

Selecting the Project Groups tab allows the pipeline designer to create arbitrary group names that can help group like projects so they can be deployed together.  Some examples could be Objects, Services and UI, which will allow deployments to be executed based on groups.  Even though we only have one project, we will still create a project group to show how to set them up.  Click the plus in the upper-right corner of the page and create a Services group.

Now we will create the pipeline, which will be a series of stages (environments), that will represent the flow of execution.  We will configure three stages that will represent Development, QA and PROD.  Stages include gates that determine whether the stage will continue to execute and steps that perform the work when the gates are successfully completed.  Let’s start with adding the Development stage and clicking on the view/edit button () that will contain the following by dragging the gates/steps from the right to the appropriate gate or step pallete:

  1. No gates – nothing will hold up the step execution
  2. Deploy All Step – deploy all projects that match the configured Project Group
  3. Test All Step – run all tests configured on the deployed projects

Since there’s no gate, we can start by creating the Deploy All Step.

Now add the Test All step after the Deploy All step.  This step will match against the Testing Strategy and execute the appropriate tests.

After clicking OK, click on the plus () in the upper-right hand corner to go back to the main pipeline page.  Now we will add the next stage (QA) in the same fashion but with the following gates/steps:

  1. Test Gate – only allow the stage to continue if the test in Development was successful
  2. Approval Gate – internal approval that will hold up the stage execution until the approval occurs
  3. DeployAll Step – same as Development

Start with the Test Gate.

Now add the Approval Gate in series (on the same line) with the Test Gate, so both gates must be satisfied to move onto the step execution.

Now add the same Deploy All step so we deploy the same projects to this environment.

After clicking OK, click on the plus () in the upper-right hand corner to go back to the main pipeline page.  Now we will add the next stage (PROD) in the same fashion but with the following gates/steps:

  1. External Approval Gate – external approval that will hold up the stage execution until the approval occurs in ServiceNow
  2. DeployAll Step – same as Development

Start with the External Approval Gate.

Now add the same Deploy All step so we deploy the same projects to this environment.

After clicking OK, click on the plus () in the upper-right hand corner to go back to the main pipeline page.  The pipeline should look like the following with 3 stages. Click on the Make Active button so this version is ready to run.  Click Save to save the entire pipeline configuration.

Now that we have a pipeline created, we can switch to the Release page and create a release by clicking on the Create Release button.

Once we have the release created; we will configure the name, projects and pipeline.  Once configured, we need to start the release and then save the release configuration.

  1. Name – select a meaningful name for the release
  2. Description – add a description
  3. Pipeline – select the pipeline that was just created from the drop down
  4. Projects – just start typing the project name in the text box next to the Add Project button and the search will find the project(s).  Once you find the project, click on the Add Project to add it to the release.
  5. Project Group – after a project is added to the release, then you can assign a Project Group that we created previously to each project. This will be used by the Deploy All steps.
  6. Start the Release

One last configuration is required because we added an external approval gate to the PROD stage in the pipeline.  Click on the Change Management tab and select the ServiceNow instance from the drop down.

Since we only added the external approval to the PROD stage, we need to adjust the Environment Configuration by selecting the Override setting button and then selecting the Environment Configuration tab.  Add the PROD environment and then click on the Require Change Management Ticket for Deployment, this will force the user to enter in a ticket to continue with the approval process.  Make sure to save the release.

One last configuration change, we need to adjust the Poll SCM Trigger on the PROCESS_HR_REQUEST project.  Open up the PROCESS_HR_REQUEST (FlexDeploy/HR OIC) and select the Continuous Integration (yellow) tab.  Since we added this project to the newly created release, it will appear in the Release drop down.  Configuring a release on the Poll SCM Trigger will automatically create a snapshot on a successful build and deliver that snapshot to the release for deployment.

Execution

Now that we have everything configured we can run an end to end execution. Configuration built include:

  • OIC change detection
  • saving the changed OIC integrations to GIT
  • project level change detection on the project in GIT
  • automated build of the artifacts
  • automated testing of the integration
  • automated deployment through Development, QA and Production environments

We will make a change to the integration in OIC that will trigger the OIC change detection and show the automation that is in place to move the change to Production.  The CheckForOICChanges project will show a new execution due to detecting the change.

Within the polling interval (5 minutes) on the PROCESS_HR_REQUEST project, a new execution will appear that will build the project and deliver the snapshot to the configured release (BlogRelease).  With no gates on the development stage, the deployment will be automatically deployed to the Development environment and the configured tests will be executed.

Now we can look at the release in the dashboard and view how the release is executing.  Select the Release page, select the BlogRelease and then Release Dashboard.  We can see that the Development stage has been executed successfully and we are waiting on the Approval gate in the QA stage.  Once we approve the change, the QA stage will execute.

Clicking on the green hand will approve the change for the QA stage and start the deployment of the changes.  Once complete, the execution will move onto the Production stage.

Final deployment to Production requires an external approval through ServiceNow.  The ticket in ServiceNow needs to be entered on the release through the paperclip at the top of the stage.  Once the ticket number is entered, the gate will periodically check the status of the ticket in ServiceNow and hold the gate execution until the ticket is approved.  Once the ticket is approved, the gate will complete and the execution in the Production stage will begin.

After completion of the deployment to the Production server, the completed release will look like this.

Conclusion

This was the fifth blog for the FlexDeploy Loves OIC series and covered how to configure FlexDeploy for release automation of the OIC integration created in previous blogs in the series, building upon each one.  With the completion of this blog, we have tied each of the blogs together to show an overall process of detecting changes to delivering that change to Production.  In the final blog in the series, the management of shared OIC components (connections, libraries and lookups) will be covered.

Previous Post: FlexDeploy Loves OIC: Automated testing

Next Post: FlexDeploy Loves OIC: Manage connections, lookups and libraries

Dan Reynebeau

I have been working with Oracle and IBM integration technologies, along with custom development, for over 20 years providing solutions to the customer. While working with the different platforms, I have developed deployment scripts along with utilizing 3rd party deployment products to automate the deployment process. As a Principal architect at Flexagon I work with customers to enable DevOps/CI solutions using FlexDeploy, as well as primary development of FlexDeploy.

More posts by Dan Reynebeau

Leave a Reply

Your email address will not be published. Required fields are marked *