FlexDeploy Demo Details
FlexDeploy Demo Details
Sample Projects
PetClinic (Spring)
- 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)
DemoJetApp (Jet)
- 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)
Sample Topology
Environments
- 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.
Instances
- 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
- 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).
Topology Overview
- 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.
- At the top of the table, there is a tab namedÂ
Sample Workflows
War Build
- 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.
- The first step in the workflow isÂ
War Deploy
- 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.
Jet Build
- 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.
- The first step isÂ
Jet Deploy
- 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.
Sample Release and Pipeline
Demo Release
- 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.
Demo 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 (orfdadmin
) 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.
Security
Groups
- 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.
Users
fdadmin
is the built-in admin user, and is in theFD Administrators
group.Âoperator
is a user in theÂOperators
group.developer
is a user in theÂDevelopers
group.releasemanager
is a user in theÂRelease Managers
group.
The following macros are not currently supported in the footer:
- style