FlexDeploy Demo Details

Sample Projects

PetClinic is a simple, and functional, Spring application. It has a few different pages that allow users to search or add data.
The source code is located in the Samples GitHub Repository, under spring/petclinic.
The application is configured to be deployed to the Development and Production Tomcat servers, which are also installed on the Virtual Machine
It is accessible by navigating to:
- http://[host]:8010/petclinic (for the Development Tomcat server)
- http://[host]:8020/petclinic (for the Production Tomcat server)

This is another simple application built with Oracle Jet.
The source code is located in the Samples GitHub Repository, under js/Jet/DemoJetApp.
The application is deployed to the Development and Production Tomcat servers, also installed on the Virtual Machine
It is accessible by navigating to:
- http://[host]:8010/jet (for the Development Tomcat server)
- http://[host]:8020/jet (for the Production Tomcat server)

There are 3 sample environments configured in FlexDeploy:
- Build (BLD)
- Development (DEV)
- Production (PRD)
The Build environment is used to perform builds.
The Development environment is where projects are deployed to for testing before they go into production.
The Production environment is where the finished application is deployed to be consumed by the customer.

There are 2 sample instances configured in FlexDeploy:
- Build
- Tomcat
The Build instance is used for building projects, so it is associated to the Build environment. This association allows us to configure Environment/Instance properties required for the plugins used in the build workflow.
The Build instance has plugin operations such as runMaven(Maven), saveArtifacts(File), and execute(Unix Shell), all of which are used for building projects and adding files to the Artifact Repository.
The Tomcat instance is used for deploying Tomcat applications. It is associated to both the Development and Production environments, as we will deploy Tomcat applications to both environments.
There is also an Apache JMeter instance which is used for unit testing the PetClinic application (defined under Integrations - Testing).

Endpoints are the actual servers where FlexDeploy will execute plugin operations (i.e build and deployment steps).
There are 3 sample endpoints:
- DEVSERVER1
- PRODSERVER1
- LOCALHOST (automatically created with a new install)
The endpoints are associated to the intersection between an instance and an environment:
- Build/Build → LOCALHOST
- Tomcat/Development → DEVSERVER1
- Tomcat/Production → PRODSERVER1
All 3 endpoints use localhost as the endpoint address, but are created as separate endpoints to demonstrate how endpoints would be created when the target servers are not installed on the FlexDeploy server (in a real world implementation).

The Topology overview allows mapping Environment/Instance pairs to endpoints, and setting values for their properties. The endpoint associations are:
- Build/Build → LOCALHOST
- Tomcat/Development → DEVSERVER1
- Tomcat/Production → PRODSERVER1
- Apache JMeter/Development → LOCALHOST
- Apache JMeter/Production → LOCALHOST
Click on the green baloon for DEV/Tomcat. We will see a list of Environment/Instance properties. Note that the properties marked with * are required.
- At the top of the table, there is a tab named Endpoints (1). This is where an Endpoint is specified for an Environment/Instance pair.

This is the workflow used for building the PetClinic project. It is fairly simple, with only 3 steps:
- The first step in the workflow is Clone Project Sources. This is an operation on the Git plugin which clones the source configured on the project (PetClinic).
- The next step is Build War with Maven, which uses the runMaven operation on the Maven plugin to build the war file.
- The third and final step is Save Artifacts. This operation of the File plugin simply saves the war file and the JMeter test file to the Artifact Repository.

This workflow only has one step, Deploy War to Tomcat.
It uses the deployWar operation of the Tomcat plugin.
The operation simply takes the artifact from the build (war file) and deploys it to the target Tomcat server.

This workflow is used to build an Oracle Jet project, and has four steps:
- The first step is Clone Project Sources. This is an operation on the Git plugin that clones the source configured on the project (DemoJetApp).
- The second step uses the execute operation of the Unix shell plugin to execute a shell script containing the ojet restore command.
- The next step uses the same operation to execute the ojet build command.
- The fourth and final step is Save Artifacts. This operation of the File plugin simply saves the artifacts to the Artifact Repository.

This workflow is used to deploy a Jet project to a Tomcat server.
The workflow has an Environment/Instance property created called JET_ARTIFACT_TARGET_PATH (as the value is different by environment).
The first step is Copy Artifacts, which is a File plugin operation used to copy build artifacts to a location on the endpoint.
The second and final step is another Unix Shell execute operation, used to update the file permissions of deployed artifacts.
Since FlexDeploy does not have an out of the box plugin for Oracle Jet, this provides an example of how to integrate technologies using scripting.

This release is configured for both sample projects.
The Primary Manager on the release is the releasemanager user, and there is no secondary manager.
There are 3 snapshots for the release which have successfully executed the entire pipeline.

This pipeline first deploys all projects to the Development environment, then executes all of the unit tests configured on the projects (only PetClinic has defined unit tests).
Next, a test gate will check the results of those unit tests to determine if the project can be deployed to the Production environment.
After the test gate checks the test results, the operator user (or fdadmin) must approve the deployment.
Once the deployment is approved, a scheduled task is created to deploy to the production servers at 9pm on Saturday.
Once the schedule is met, or the release manager skips the gate, all of the projects are deployed to the Production environment.

There are a few sample groups created in FlexDeploy, to demonstrate the fine-grained permission model.
- FD Administrators is a built in group for administrators with all permissions across FlexDeploy.
- Operators is a group for the Operations team, which has permission to view all screens in FlexDeploy, as well as creating Windows, Approvals, Notifications, and updating Approval and Scheduled Tasks.
- Developers is a group created for the Development team, with permissions to perform builds, and deploy to the Development environment.
- Release Managers is a group with permissions to deploy to Development, as well as creating and updating Releases and Pipelines, and creating a Snapshot for a release.