Skip to main content
These steps can be useful if you are installing a new FlexDeploy environment, and want to load it with specific configurations from a different environment but without execution data. For this process, the source environment must be same FlexDeploy version as the target. These steps are provided as guidelines and extreme care must be taken to not disrupt your production environments.
This process should only be followed to perform configuration setup for brand new installation of FlexDeploy from another installation of FlexDeploy. The purpose of this document is to only copy configuration details and not execution data. If you run this against active Production FlexDeploy, you will lose all execution details.The source and target version of FlexDeploy should be the same, or you can run the installer and upgrade the target to a higher version if desired.
  • Stop the source FlexDeploy server in order to take cold backup, or if you have Flashback enabled on the database, you can use FLASHBACK_TIME = SYSTIMESTAMP
  • Export data from source FlexDeploy database. (FF, FD, FD_ADMIN). DBA/admin to perform the activity.
  • **Plugin folder backup from Source FlexDeploy(This step is needed only if changes were made to any plugin) :**Take backup of plugins folder using tar/zip commands on source FlexDeploy server. Plugins folder is under server working directory. You can determine working folder by looking at flexagon.fd.application.root system property on server command line. For example,
    • cd /flexdeploy/application/plugins
    • tar -czvf /app/backup/flexdeploy_plugins.tar.gz *
  • Cleanup Target FlexDeploy Database Tables before import
  • Run the following sql command for the target database that will generate many drop table, view statements as output.  Once this sql is complete, copy all of the output and execute that against the target database. The command needs to be executed preferably with sys user. This method will drop all of the data but maintain table spaces, quotas and passwords for the given schemas.  This will also maintain the same password that is stored in the context.xml file. Oracle DB: Drop tables, views and procedures without dropping user
  • FD,FF schema contains 4 type of object TABLE, VIEW, INDEX & LOB. You can use below query to verify the same.
  • Index gets deleted automatically once the Table gets deleted.
  • With Table deletion the Lob type also should be deleted automatically, unless the recycle bin is turned on in the database.
  • In case recycle bin feature is on, even after Table deletion the Lob type still exists. Since the tables are still present in recycle bin and not completely deleted. Please execute below command to cleanup recycle bin and delete the Lob types automatically.
  • Stop target FlexDeploy server at this point. 
  • Import data into target FlexDeploy target database. (FF, FD, FD_ADMIN). DBA/admin to perform the activity.
  • At this point the target FlexDeploy database would be an exact copy of the source database. Often times you will not need or want any of the execution details, so let’s delete execution data using following commands. Make sure to run these commands on the target FlexDeploy database. Keep in mind that in this process we have not copied artifact repository as our goal was to not include execution details.
    • If there are errors in delete process below you can run it multiple times. In case of issues, please contact us at http://support.flexagon.com.
  • Delete execution data in target FlexDeploy database using below scripts.
  • Note : You may have to repeat the delete execution 2-3 times to make sure all commands are executed successfully. Since it may happen due to some foreign key restriction the deletion failed on first attempt.
  • Execute the following delete statements for FlexDeploy 9.0
  • Above commands will not delete the Release and packages created in source FlexDeploy instance. Some customer may want to keep the data or they may want to delete them.
  • To delete Release & Package details from the database execute below commands.
  • To delete oAuth configuration
  • We will not copy any Artifact Repository in this process, as we are purging the execution data.
  • We recommend that you copy the Application folder from source to target. It contains the plugins and the influx database. You can skip the .gitrepos folder to save space.
    • If you don’t copy application/vsm/data, and you have an existing target server, after server restart you will probably get a Notification on top-right corner stating that the influx credentials are invalid: image-20251119-125142.png
    • If you do copy application/vsm/data, and you want to remove the execution statistics from the source server,
  • FlexDeploy on the target server can be installed before or after the database copy activity. If you have an existing FlexDeploy install on the target (cloning over dev for example) then no need to copy it again. If it is a new dev, you can copy the FlexDeploy home from the source server and modify the server.xml and context.xml files on the new dev server. If the installer will be used, it is a good time to copy the installer folder and modify the installer config at this time also.
  • if the target will have a newer version of FlexDeploy than the source, follow the FlexDeploy Upgrade process after the database clone. Read the prompt carefully. It should say it is going to upgrade. If not, choose N then follow the directions by the prompt carefully.
  • At the end of process, start FlexDeploy and validate that your configurations are present in various screens.
Consider if you would like to make any of the database changes mentioned at FlexDeploy Clone from Production to Test .  As part of final configuration, please modify FlexDeploy configurations as required like:
  • server base url (FD_SERVER_BASE_URL)
  • Security realm -group, user configurations
  • Email server settings - From mail address(SMTP_FROM_ADDRESS).
  • Also please update the Integration details , in case the Dev & Prod FlexDeploy server target details are different.