FlexDeploy supports architecture where customers have strict network isolation between various environments. For example, production environment (and possibly more) is setup set up such that it cannot access source control, 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 environmentenvironments, then copy execution details in zip format from source environment to other environments. This would allow implement implementing a build once - deploy many approach and still maintain necessary security practices.
...
FlexDeploy is installed on each isolated environment, and plugins are also installed as part of 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 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 the source server. Configuration export will be done for import to Target target server. Topology Target properties and Endpoints will be managed individually on each target server.
...
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 source tomcat server will following command line option.
...
| Code Block | ||
|---|---|---|
| ||
FLEXAGON_FD_JAVA_ARGS="-Dflexagon.fd.isolatednw.targetserver=true" |
| Tip |
|---|
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 Source source environment for Projects, Environments, Target Groups etc. Additionally, map Environments with Target Groups as well, making sure to include isolated environments.
Perform configuration export from Source source server and import on to Target onto target as and when necessary. This export can be done by using from Administration - Admin Operations optionpage.
Builds can be exported individually from each workflow execution page or as a group from Release Snapshots page.
All export files (configuration, build, snapshot etc.) should be placed in fdexports sub-folder on Server server working directory on Target 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 target server, then the release will be created as with the status set to Not Started, this . 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.
...
FlexDeploy configurations can be exported which includes the environments, target groups, workflows, and projects of the server. The user must have administrator privileges and to download the server configuration can be downloaded from the admin operations menu. To do this, go to the Admin Operations screen (Menu → Administration → Admin Operations) screen and change the operation name to : Export Configurations, then click the Create button that appears.
...
| Tip |
|---|
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 , 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. |
...
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.
...
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.
| Tip |
|---|
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 , 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 with a build containing the package (see Export Builds) or with a if the chosen snapshot of a release containing the project and its packagescontains the package. |
Once the snapshot is exported successfully, it can then be imported to an Isolated Network Target Server.
...
Build workflow executions can be exported from any project assuming that they completed successfully. To do this, go to the executions Execution tab of a project and click on the id of a successful build.
...
The exported build will contain all related data as well as the 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 |
|---|
Note that the project configuration must also exist on the target server in order for the import to be successful. See Export Configurations. |
Import on Target Server
First make sure your you are using connected to a target server. Then you must take an export and put it inside of your fdexports folder, this . This may be flexdeploy<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.
...
If FlexDeploy is running, it will automatically start the import process shortly and delete the zip file from your fdexports folder once import is completed. This may take a few minutes to get started. This same 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
Snapshots and configurations import may take a longer, but builds should be imported fairly quick.
Configurations can be imported many times as configurations change on source server. Import process will handle the import with necessary create, update, delete.
...
| Note |
|---|
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’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.
Target Server Assumptions
Topology: Target Groups and Environments must be configured on the source server and imported to any target servers. Environments, Workflows, and Property Sets must also be assigned to Target Groups on the source server. Environments cannot can not be mapped or unmapped from Target Groups on 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 cannot 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. The only editing that can be done to Projects on the target server is adding group permissions on a project or folder.
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.
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 between source and target servers.