FlexDeploy Clone configurations/steps for fresh installation

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 must be the same.

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

select 'drop table ' || owner ||'.' || table_name || ' cascade constraints PURGE;' from dba_tables where owner in ('FD','FD_ADMIN','FF')
union all
select 'drop view ' || owner || '.' || view_name || ';' from dba_views where owner in ('FD','FD_ADMIN','FF')

FD,FF schema contains 4 type of object TABLE, VIEW, INDEX & LOB. You can use below query to verify the same.

select distinct object_type,count(1) from dba_objects where owner in('FD','FF') group by object_type

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.

purge dba_recyclebin;

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.

Above command 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.

We will not copy any Artifact Repository in this process, as we are purging the execution data.
Plugin folder restore to target FlexDeploy(This step is needed only if changes were made to any plugin) :Copy plugins tar/zip file to target FlexDeploy server and extract it in the plugins directory under working directory. You can determine working folder by looking at flexagon.fd.application.root system property on server command line.
- cd /flexdeploy/application/plugins
- rm -rf *
- tar -xzvf /app/backup/flexdeploy_plugins.tar.gz
FlexDeploy in target server should ideally be installed before the database copy activity(as per steps in FlexDeploy Installation Guide). However it can be installed in target environment after database copy as well but skip database tier as it was already copied from a different environment.
You can also follow the FlexDeploy Upgrade process if the target will have a newer version of FlexDeploy than the source.
At the end of process, start FlexDeploy and validate that your configurations are present in various screens.

Potential issue with Influx Database. Post server restart you may get a Notification on top-right corner stating error message as shown below:

To resolve this issue please follow the steps mentioned in below link

https://flexagon.atlassian.net/wiki/spaces/SHAR/pages/10198024211/InfluxDB+in+FlexDeploy#Resolving-unauthorized-access-Issue

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.