Skip to main content
FlexDeploy supports architecture where customers have strict network isolation between various environments. For example, the production environment (and possibly more) is set up such that it cannot access source control, or artifact repositories and the environment itself cannot be accessed from other environments via SSH or HTTPS. This is done mostly for security reasons. Customers employing this type of security architecture can install FlexDeploy in each of the isolated environments, and then copy execution details in zip format from the source environment to other environments. This would allow implementing a build once, deploy many approach and still maintain necessary security practices.

​
Assumptions

  • FlexDeploy is installed on each isolated environment, and plugins are also installed as part of the installation.
  • All FlexDeploy installations participating in isolated network architecture must be at the same version. At times, even minor releases also introduce database changes, so a strict version match is required.
  • There will be only one such source server, but there can be one or more such target servers.
  • Builds are executed on the source server and are imported to the target server(s). Builds can not be performed on the target server.
  • Environments, Target Groups, Projects, etc. will be configured on the source server. Configuration export will be done for import to the target server.
  • Topology
    • Target Groups and Environments must be configured on the source server and imported to any target servers.
    • Environments and Property Sets must also be assigned to Target Groups on the source server and imported to the target server.
    • Endpoints can be created and assigned to Targets on the target server. Also, property values can be edited for Targets on the target server.
  • Projects
    • Projects can not be created or configured on the target server. Projects can only run builds on the source server, which can then be imported to the target server where they can be deployed and tested.
    • Folder and Project issue tracking configurations should also be managed on the source server and imported on the target server.
    • Project and folder security is managed separately on source and target servers.
    • Folder settings are managed only on the source server and imported to any target servers.
  • Release
    • Releases and Snapshots can be created on the target server. However, since build can not be performed on Projects on the target server, these can only be created with existing project versions.
    • Release-level Settings and Security can be managed on target servers.
  • Pipeline
    • A pipeline must be created on the target server as it will handle deployments to different endpoints than the source server. Note that the source server may be deploying to zero or more environments depending on isolation requirements.
  • Integrations
    • Integration Providers can not be created on the target server and will be imported from the source server. Integration Instances can be created on the target server.
  • Security
    • All users, groups, and permissions are managed separately on source and target servers.
  • Workflows cannot be configured on the target server, hence must be imported from the source server. Workflow-level security is not allowed on target servers, must use global permissions for workflow security.

​
Configuration

The following assumes that you have upgraded to use setenvoverride.sh (or setenvoverride.bat) files. If you are still using setenv.sh, then changes will be slightly different. Configurations shown below must be performed in addition to following the installation document or automated installation process. Configure the source tomcat server with the following command line option.

​
Source environment setenvoverride.sh

Configure the target tomcat server with the following command line option. The Target server will have limited capabilities (i.e. no builds can be performed), and it will use different sequences for generated ID values.

​
Target environment setenvoverride.sh

Internal key blocks will be set to start on very large number on target servers, this is done to avoid key collisions as various configuration and build data is imported from source to target server. For this reason, FlexDeploy must be started as target server and it can not be configured as target server once it has been utilized.

​
Execution

  • Make sure to configure the source environment for Projects, Environments, Target Groups, etc. Additionally, map Environments with Target Groups, making sure to include isolated environments managed by target servers only.
  • Perform configuration export from the source server and import onto the target as and when necessary. This export can be done from the Administration - Admin Operations page.
  • Builds can be exported individually from each workflow execution page or as a group from the Release Snapshots page.
  • All export files (configuration, build, snapshot etc.) should be placed in fdexports sub-folder on the server working directory on the target server. Files will be automatically imported and deleted on successful import.
  • If you are working with snapshot export and the release does not yet exist on the target server, then the release will be created with the status set to Not Started. This means that the snapshot is only partially imported. You must associate a pipeline to that release and then start it. Snapshot import will be completed after that automatically.
For more information on utilizing Isolated Networks see here. Image Note that very strict security restrictions in such configurations require manual copies of files, this is mainly driven by security practices of specific organizations.

​
Export from Source Server

FlexDeploy allows Configurations, Builds, and Snapshots to be exported. For these options to be enabled, FlexDeploy must be configured as an Isolated Network Source Server. See the Configuration section above.

​
Export Configurations

FlexDeploy configurations can be exported which includes the environments, target groups, workflows, and projects of the server. The user must have administrator privileges to download the server configuration. To do this, go to the Administration → Admin Operations screen and change the operation name to Export Configurations, then click the Export button that appears. Image
The configuration export may take some time depending on the amount of data on the server.
The configuration export zip contains the configuration for the whole server including the topology (environments, target groups), workflows, and projects.
Test automation, triggers, and tags will not be included with project exports and they cannot be reconfigured on the target server. Test and scan results will be exported if they are associated with a build execution, meaning test, utility, and deploy executions will not be exported. Additionally, credentials are not exported, meaning all cloud accounts and source control management passwords associated with a project will have to be reconfigured on the target server. Project packages and artifacts will only be exported with a build containing the package (see Export Builds) or with a snapshot of a release containing the project and its packages.
Once the configuration is exported successfully, it can then be imported to an Isolated Network Target Server.

​
Configuration Export Content

  • All Workflows (Internal and Read-only workflows are excluded).
    • Only active version. The version will be activated on the target server on import.
    • Workflow Properties (Property Set).
  • Topology
    • All Environments and Target Groups.
    • Target Group mappings with Environment and Workflow / Plugin Operations. Note that Target Endpoint and Property Value configurations are not exported.
    • Custom issue tracking systems including their Properties.
    • SCM and Issue Tracking integration instances with Property Values. The Credential used for property value is not imported, hence it will need to be set on the target server. Once the credential is set up, it will be kept as is for future import of the same Integration Instance.
  • All Folders
    • Folder level Release Settings.
    • Folder level issue tracking configurations are exported since FlexDeploy 8.0.0.1 only.
  • All Projects
    • including sources, branches, workflow, and target group configurations.
    • Project File Catalog.
    • Project Property Values.
    • Test, Replacement, and Issue Tracking Configurations.

​
Export Snapshots

Snapshots can be exported from any release assuming that they were :Initiated: Initiated. To do this, navigate to the Releases screen and click on a release from the folder content. Image From here, go to the Execution tab, click on the actions menu of a snapshot that was :Initiated: Initiated, and then click Download Archive Image
The snapshot export may take some time depending on the amount of data on the server.
The exported snapshot will contain all of the server’s configuration at the time of the release, as well as any build executions associated with the snapshot for the projects and packages in the release.
Test automation, triggers, and tags will not be included with project exports and they cannot be reconfigured on the target server. Test and scan results will be exported if they are associated with a build execution, meaning test, utility, and deploy executions will not be exported. Additionally, credentials are also not exported, meaning all cloud accounts and source control management passwords associated with a project will have to be reconfigured on the target server. Project packages and build artifacts will only be exported if the chosen snapshot of a release contains the package.
Once the snapshot is exported successfully, it can then be imported to an Isolated Network Target Server.

​
Snapshot Export Content

  • Only Successfully built snapshots can be exported.
  • Release definition including project content.
  • Snapshot versions including workflow execution details for each project version
    • Build execution and project version (including package) details
    • Build Artifacts
    • Associated Work Items and Commits
    • Scan and Test results
    • Build Request details including Inputs
  • Project details of all projects in the Release
    • including sources, branches, workflow, and target group configurations.
    • Project File Catalog.
    • Project Property Values.
    • Test, Replacement, and Issue Tracking Configurations.

​
Export Builds

Build workflow executions can be exported from any project assuming that they are completed successfully. To do this, go to the Execution tab of a project and click on the id of a successful build.
If a specific workflow execution was previously imported, it will not be imported again.
Image On the workflow summary section in the top right corner, there is a download button that will export this build: Image
If the downloaded file is instead a .txt with the message “Failed - Needs authorization” (shown below) then log out and into FlexDeploy and try again.
Image The exported build will contain all related execution data, artifacts, and package data associated with the execution. Once the build is exported successfully, it can then be imported to an Isolated Network Target Server.
Note that the project configuration must also exist on the target server for the import to be successful. See Export Configurations.

​
Build Export Content

  • Only successful builds can be exported.
  • Build execution and project version (including package) details. The package will be Activated on import if it was previously completed.
  • Build Artifacts
  • Associated Work Items and Commits
  • Scan and Test results
  • Build Request details including Inputs

​
Import on Target Server

First, make sure you are connected to a target server. Then you must take an export and put it inside of your fdexports folder. This may be <flexdeploy_home>/application/fdexports depending on how FlexDeploy was installed. To do this, you may use any file transfer tool or method available and approved by your network and security teams. Image If FlexDeploy is running, it will automatically start the import process shortly and delete the zip file from your fdexports folder once the import is completed. This may take a few minutes to get started. This same process can be done with exported builds, snapshots, or configurations. Snapshots and configurations import may take longer but builds should be imported fairly quickly. Configurations can be imported many times as configurations change on the source server. The import process will handle the import with necessary create, update, and delete. Image Image
When a new plugin is installed on your source server, make sure to also install it on your target server prior to importing.
Snapshots will not import if there isn’t a pipeline associated with the release on the target server. To solve this problem, go to the releases page and click on the release. In the top left below the release’s name, hover over the pipeline symbol and click on the edit pencil, lastly select a pipeline and click the checkbox to save. Then the snapshot will finish importing automatically. For more information on associating a pipeline with a release, see the pipeline and release documentation.