This is the fifth 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 the next four blog articles 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
Workflows are a sequence of operations to implement the build or deployment for a technology into a single environment. There are several different types of workflows, but here we will focus on the build workflow and the deploy workflow.
Workflows are highly re-usable as they are parameterized and executed in context of a project and the target environment through the use of project/environment properties defined in FlexDeploy.
A build workflow is responsible for collecting the source and packaging it into an artifact (sar file), which is then versioned in FlexDeploy’s internal artifact repository. The deploy workflow is then responsible for taking a versioned artifact and deploying it into the target server.
Workflows, while powerful, are generally very simple since they are task oriented. They are also simplified by making use of out of box FlexDeploy plugins, which understand the underlying technologies and provide functions to perform the heavy lifting.
The build workflow uses:
- An out of box child workflow (SCM-ExportSource) that will extract the code from configuration details on the project, such as location and SCM Type.
- The soaBuild operation from the Oracle SOA plugin with default configuration.
The deploy workflow uses the soaDeploy operation from the Oracle SOA plugin with a couple configuration options as shown below:
- Utilizing the Deploy Config Plan project allows for environment to environment URL cleanup, these can be project based, environment based or global (which is being used in this article). Add link to a sample file?
- Activating Purge On Deploy to manage the number of revisions that are on a given server. The number of revisions kept is controlled by an environment instance property (Composite Revisions to Keep).
Unless we later want to add logic to implement specific use cases or add test calls, we would never need to revisit the workflows again for Oracle SOA. Do not confuse a workflow with the orchestration of deploying across a series of environments. That is what is called a pipeline in FlexDeploy, and will be covered in another blog article in the series.
The topology defines the physical and logical architecture, environment specific properties, and connections to other tools. The logical architecture is defined by environments and instances. Examples of environments would be Development, QA, and Production. These are logical in that they are not directly bound to any technology. An instance is specific to a technology, but not any specific environment. For example, if you have a single SOA server, which has physical installations in many environments, this is represented by a single logical FlexDeploy instance. If you have, for example, separate SOA installation stacks for critical and non-critical services, these would be represented by two instances.
For this blog article I have created four logical environments. The environments are simply a name without any additional configuration, other than to indicate builds will be performed in Development, and the other environments are for deployments only.
One logical instance, simply called “SOA”, has been created in the previous article. Oracle SOA utilizes the SOA installation thus we can utilize the same instance for MDS, Service Bus, and SOA. Additional configuration will be required on the SOA instance to add the additional SOA workflows.
This instance has been associated with the three environments where I have SOA installations.
And I have indicated that build and deploy workflows for MDS will be executed on this instance.
Now we will define the physical architecture, which is represented by what are called endpoints. An endpoint is an SSH connection to a physical server. The definition of the endpoint, in addition to a name, includes the host address, credentials (password, or SSH keys), a directory that resides on the host which can be used by FlexDeploy at runtime, and the location of the JDK installed on that server.
Lastly the logical architecture must be mapped to our physical architecture. Here, in the “Topology Overview“, since I mapped the SOA instance to the three environments, a configuration matrix is formed.
By clicking on the balloon for each environment I can bind it to the associated physical endpoint(s) and provide values for environment specific properties. Here I have indicated that SOA in Development has a single endpoint called “SOADEV”.
Since I mapped the SOA instance to the build and deploy workflows we created, the required and optional environment specific properties appear. I provided the values for these properties, as applicable for my Development SOA installation. I have completed the same endpoint mappings and property value configuration of the SOA instance for QA and Production.
Finally, I will define a connection to my source control system. For this blog article I am using GitHub to host my SOA Composite. A connection has been created to the repository, defined by a URL and the credentials.
That concludes the topology configuration. I will later add additional workflows to this configuration and that will add additional properties that will need to be configured.
The next step in the configuration is to define one or more projects, which will be bound to the workflows, instance, and a SCM. There can be one to many projects for SOA, there is typically one project for each SOA composite.
For this blog article I have created one project to manage orders. When creating the project, I gave it a name of ValidateOrderProcess and made it a standard project.
After creating the project, I have set the following configuration on the configuration tab.
The SCM Type is set to “Git”, but there are options available for all popular source control systems. I have bound the workflows I created for SOA, and bound the Build Instance and the Deploy Instance as “SOA”. Notice that the environment is not provided here, as the particular environment will be specified during the build and deployment requests.
Under the SCM Configuration, the Git Instance that was created in topology is selected. The SCM properties are specific to the SCM type, and the values are expressions implemented in the Groovy scripting language. Back to these in a moment.
The Streams correlate to the branches in the Git repository from which the project will be built from. In this example, a master branch was created to manage the code, but additional streams for other branches can be added as required.
Now back to the SCM instance properties. The Branch Name Script is set to use the “StreamName” variable. This will resolve to the stream that is selected in the build request. The other property to pay attention to is the Sparse Checkout Folders Script. This is the path relative to the repository where the source is located for this project. For this example, my source is located in the “SOA/SOAWebinar/ValidateOrderProcess” folder within the configured Git repository. To simplify configuration, and not have to change it for each project, a Groovy script was used (“SOA/SOAWebinar/” + ProjectName). When the project is built, the value of “ProjectName” will resolve accordingly at runtime.
Now let’s switch over to the Properties tab. Since I bound the project to the SOA workflows, which use the Oracle SOA plugin operations, their project-scoped properties are displayed for this project. There are several properties which can be set to influence behavior, but there is one that will be updated, called SOA Partition.
Adhoc Build & Deployments
Now that we have completed the configuration, we are ready to execute build and deployments. To do this, we switch to the green Execution tab, and click on the “Build” button.
Note that I only have one build environment, and one stream, so they are pre-selected. Click “Submit Request” to initiate the build request. We now see the build request and its execution being processed.
By clicking on the execution id, the execution of the build workflow can be viewed. Each step of the build workflow will be displayed. The link below each step will show the logs for the step.
Once the build is complete the generated artifact will be available on the Artifacts tab. The resulting artifact is versioned in the artifact repository using the generated Project Version number.
Going back to the main execution screen a deployment request can be submitted to deploy the project version into one or more environments. Click on the “Deploy” button. This will launch the deployment request form for the previous build request. Here the target environment is selected and the request is submitted. Now we see the deployment request and its corresponding execution.
When drilling into the execution we see the steps of the deployment workflow and see that the workflow execution itself is successful. Again, we can drill into the logs for the deployment to see the deployment command that was executed and the resulting output. Click on the “Deploy” button and select another environment to deploy objects to the next environment.
In this blog article, the steps were shown on how to configure FlexDeploy as an automation solution for building and deploying Oracle SOA composites across various environments. Configuration included a one time setup for workflows, topology, and projects. The core setup positions us for making adhoc requests to assemble source changes from Git into a SOA composite artifact, and deploy that artifact into any environment. In the next blog article in the series, continuous integration and issue tracking will be added to the solution.