At the completion of this section, you will:

Understand the use of workflows in the deployment process
Be able to create/modify a build workflow
Be able to create/modify a deploy workflow

A workflow is an orchestration of configurable steps that define a process and determine how the deployment process will execute. Workflows are created once and then configured on multiple projects to define the execution for that project.

There are several types of workflows that can be created (only build and deploy will be used in this tutorial) :

build

Utilized for building a project. Building a project requires retrieving the source files from the Git repository using the cloneProjectSources operation of the installed GIT plugin and saving a properties artifact using the s aveArtifacts operation of the installed F ile Plugin. The cloneProjectSources operation allows the Git repository information for the project to be defined once on the project and then retrieved from the project on execution.

deploy

Utilized for deploying a project. Deploying a project requires retrieving the properties artifact created by the build workflow and deploying the artifact using the c reateOrUpdateWeblogicConfig operation of the installed W ebLogic Plugin.

The workflows provide a consistent, repeatable and re-usable process that will be utilized for every WebLogic application.

Create Build Workflow

Now that we have a general understanding of why we need a build and deploy workflow, we can start to define the build workflow. Select Workflows from the main menu or from the Home page. Workflows are versioned and there is always a single active version that can be executed, this allows changes to be staged until ready to be activated. Select the + to create a new workflow.

The workflow details screen will allow for the configuration of the build workflow.

Providing the workflow with a functional name will help find the correct workflow when the project is being created in a later section of the tutorial.
Select Build as the Workflow Type
The Workflow Group and Workflow Subgroup are organizational folders for the workflows and the values are completely controlled by the workflow developer, so use functional names that will help find the correct workflow easier.

Save the Main configuration and the Definition tab will activate. The Definition is where the orchestration steps for the build will be configured. Configuration is accomplished by dragging the appropriate components from the Workflow Operations and/or the Plugin Operations pane into the center pane between the start arrow and end block (a drop zone will appear as you get close). There are several other features such an Workflow Inputs and Workflow Variables that will not be used in this tutorial.

Configure the Git cloneProjectSources operation by adding it to the center pane and the plugin will open for additional configuration. Since this is the cloneProjectSources operation, there is no configuration required and all composite based information will be retrieved from the project. Select OK. Clicking on any component in the workflow will open up the configuration screen for that component, if a change is needed.

Git was chosen as the Source Code Management tool for this tutorial, however, FlexDeploy supports many other Source Code Management tools and any one can be used in place of Git

Configure the File saveArtifacts operation by adding it to the center pane and the plugin will open for additional configuration. The saveArtifacts operation is used to save files from the workflow temp folder into the FlexDeploy Artifacts Repository. At the successful completion of the workflow, the cloned property file will automatically be pulled back to the artifact repository. Select OK

All plugin inputs can be a literal value, or a Groovy expression. Click the T icon to change the input to Groovy
This is the Variable Lookup button, clicking this will open a window to help find variables to use in the Groovy expression
Start typing a variable name in this box, and select the variable name we want to use. We're using FDBLD_GIT_SOURCE1_SPARSE_CHECKOUT_FOLDERS.
After selecting the variable, press Copy and Return to copy the variable name and close the popup
Paste the variable in the Groovy input box
A filter for selecting which files are saved into the artifact repository

The plugins are intelligent and eliminate as much development work as possible from the developers. Once the components are added, the workflow needs to be saved and/or activated. Saving the workflow changes will only save the current configuration to the database and is used when the developer may not be quite ready to activate these changes. When the developer wants the changes to be executed by projects, the Activate button must be selected. Once the current version of the workflow is activated, the workflow will be marked as read-only and have a green check mark next to it. Active versions can't be modified and require the developer to select Make Copy. This will create a new version and open that version up for editing, while the active version will not be changed.

Create Deploy Workflow

Create a new workflow for the deploy by selecting the +. The workflow details screen will allow for the configuration of the deploy workflow.

Providing the workflow with a functional name will help find the correct workflow when the project is being created in a later section of the tutorial.
Selecting Deploy for the Workflow type.
The Workflow Group and Workflow Subgroup are organizational folders for the workflows and the values are completely controlled by the workflow developer, so use functional names that will help find the correct workflow easier.

We will use the WebLogic createOrUpdateWeblogicConfig operation to deploy the configurations. The plugin will contact the WebLogic server to create datasources, JMS objects, and EIS entries defined in the properties file checked out with the build workflow. Configure the operation by adding it to the center pane and the plugin will open for additional configuration. We do not need to enter anything for the Properties File Path input, because the operation will default to look in the artifact directory for the properties files saved by the build workflow. Below the Inputs section, we can see the Outputs section. Here we can assign data coming back from the plugin execution to workflow variables for use later in the workflow. These are usually used in more complex workflows, so we won't be using them in this tutorial.

Now that the workflow is built, we will define any Workflow Properties we want to use. These properties will be replaced in the properties file we check out from Git. This allows us to use a single property file and change it for each environment, rather than having multiple files for every environment. Using these properties inside of the properties files also allows us to build the project once, then deploy those files to each environment without having to build again.

We're going to be creating WebLogic datasources, and more often than not require a password. It would be much too insecure to store these passwords in plaintext in the properties file we check out from Git. That's where FlexDeploy's workflow properties come in. We can create a property to store the password encrypted in FlexDeploy, then use a placeholder in the file for FlexDeploy to replace with the password during the deployment. This is useful not only for security, but also for any value that may change across environments (e.g. server names).

We'll start by creating a Workflow Property for the datasource password.

Go back to the Main tab of the Workflow
Under Workflow Properties, choose open the Add menu
From the Add menu, we can add an existing property, or create a new one. Select New Property
Properties must each have a unique code, give a meaningful code for the new property
A property display name does not have to be unique and can contain spaces. This is the name that will be displayed on the Environment Instance screen
Select the property scope, this defines where the property will be configured. We're using Environment Instance because this property will be different for each environment
Enter a good description for the property, this will make configuration easier in the future
This property is a password, so we'll set Encrypted to Yes. This will keep the value hidden from screens and logs

With the Datasource Password property created, we will also need to create one more property – SOA_TARGET. This property will be used as the target for the datasource FlexDeploy creates. We will create it the same way as the last property, except this time we can leave Encrypted set to No, because we don't need to encrypt the server name.

Make sure to save the workflow after adding the properties.

Completed 2 of 10 Sections	Continue to End Point Creation	Back to Login