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

Assumptions

• FlexDeploy is installed on each isolated network, and plugins are also installed as part of installation.

• All FlexDeploy installations participating in isolated network architecture must be at same version. At times, even minor releases also introduce database changes, so strict version match is required.

• Source server is where builds will be executed. There will be only one such source server.

• Target server is where builds will be imported and deployments will be executed. There can be one or more such target server.

• Environments, Target Groups, Projects etc. will be configured on Source server. Configuration export will be done for import to Target server.

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 installation document.

Configure source tomcat server will following command line option.

Source environment setenvoverride.sh

FLEXAGON_FD_JAVA_ARGS="-Dflexagon.fd.isolatednw.sourceserver=true"

Configure target tomcat server with following command line option. 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

FLEXAGON_FD_JAVA_ARGS="-Dflexagon.fd.isolatednw.targetserver=true"

Execution

• Make sure to configure Source environment for Projects, Environments, Target Groups etc.

• Perform configuration export and import from Source to Target as and when necessary. This export can be done by using Administration - Admin Operations option.

• Builds can be exported individually from workflow execution page or as a group from Snapshot page.

• All export files (configuration, build, snapshot etc.) should be placed in fdexports sub-folder on Server working directory on 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 as Not Started, this means that snapshot is only partially imported. You must associate a pipeline to that release and then start it. Snapshot import will complete after that automatically.

For more information on utilizing Isolated Networks see here.

Note that very strict security restrictions in such configurations require manual copy of files. This is mostly seen in Government-related projects.

FlexDeploy allows Configurations, Builds, and Snapshots to be exported. In order for these options to be enabled, FlexDeploy must be configured as an Isolated Network Source Server (see Isolated Networks Architecture).

Export from Source Server

Export Configurations

FlexDeploy configurations can be exported which includes the topology, workflows, and projects of the server. The user must have administrator privileges and the server configuration can be downloaded from the admin operations menu. To do this, go to the Admin Operations screen (Menu → Administration → Admin Operations) and change the operation name to: Download Configuration Zip Archive then click the Download Archive button that appears.

The folder contains the configuration for the whole server including the topology (environments, target groups, plugins), workflows, and projects. Please see the Properties Not Exported section for items that are not included with exports. Once the configuration is exported successfully, it can then be imported to an Isolated Network Target Server. See Isolated Networks Import Documentation.

Export Snapshots

Snapshots can be exported from any release assuming that they were initiated successfully. To do this, go to the Releases screen and click on the name of a release.

From here click on the View Snapshots button.

Then click on the name of a snapshot that was Initiated.

Lastly, click the Download Archive button in the top right corner to export the snapshot.

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 projects in the release. Please see the Properties Not Exported section for items that are not included with exports. Once the snapshot is exported successfully, it can then be imported to an Isolated Network Target Server. See Isolated Networks Import Documentation.

Export Builds

Build workflow executions can be exported from any project assuming that they completed successfully. To do this, go to the executions tab of a project and click on the id of a successful build.

On the workflow summary section in the top right corner there is a download button that will export this build:

The exported build will contain all related data as well as the package data associated with the execution. Please see the Properties Not Exported section for items that are not included with exports. Once the build is exported successfully, it can then be imported to an Isolated Network Target Server. See Isolated Networks Import Documentation.

Properties Not Exported

Test automation, triggers, and tags properties 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 and so 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 (see Export Snapshots).

Import on Target Server

First make sure your are using a target server. Then you must take an export and put it inside of your fdexports folder, this may be flexdeploy/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.

If FlexDeploy is running, it will automatically start the import process shortly and delete the zip file from your fdexports folder. This may take a few minutes to get started. This process can be done with exported builds, snapshots, or configurations. It can also do multiple different export types at once, but it may take a bit longer. Snapshots and configurations will work on an empty or full server, but an exported build may need configurations or snapshots to be imported first, as it needs an associated project to import into. Snapshots and configurations may take a long time to import, but builds should be fairly quick.

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’s id. Add a pipeline and start the release. Then the snapshot will finish importing automatically. For more information on associating a pipeline with a release, see the pipeline and release documentation.