FlexDeploy supports architecture where customers have strict network isolation between environments. For example, production environment (or possibly more) is setup such that it can not access source control, artifact repositories and environment itself can not be accessed from other environments via SSH. This is done mostly for security reasons. Customers employing this type of setup can install FlexDeploy inside 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, Instances, Projects etc. will be configured on Source server. Configuration export will be done for import to Target server.

Configuration

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.

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.

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

Execution

• Make sure to configure Source environment for Projects, Environment, Instances 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 release is not yet existing on Target server, then release will be created as Not Started, this means that snapshot is only partially imported. You must associate pipeline to that release and then start it. Snapshot import will compete 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.