Most Many customers are installing install FlexDeploy in Test and Production environments. The purpose of the Test environment is to try various patches or beta capabilities of plugins, or even trying some complex workflows and/or custom plugins. The FlexDeploy test environment may be restricted for use to by select members of the team. It is good idea to periodically (mostly when applying major FlexDeploy upgrade/patch) clone FlexDeploy Production configuration/execution data to FlexDeploy Test environment, which will allow you to easily validate new FlexDeploy upgrades  or and patches.

These steps are provided as guidelines and extreme care must be taken to not disrupt your production environments.

Make sure Target FlexDeploy is Ready

• Make sure target environment is ready

  and has same FlexDeploy version installed

  .

• Keep target FlexDeploy down for this process.

Export Import Database & Copy

...

Artifacts, Plugins, and InfluxDB data

• Export data from Production FlexDeploy database.

  You will be prompted to enter password for system user.
  This step will create fd_bkup.dmp file with all details from

  
  

  Take backup of artifact repository

  • You should export FD,FF and FD_ADMIN

    schemas. File should be in data pump directory, for example - C:\oraclexe\app\oracle\admin\XE\dpdump.
  • If your database is only used for FlexDeploy application, you may be able to perform backup and recovery operations using other Database tools.

expdp system directory=DATA_PUMP_DIR dumpfile=fd_bkup.dmp schemas=FD,FF,FD_ADMIN

• • .

• Take backup of artifact repository folder using tar/zip commands on Production FlexDeploy server. (Optional if you won’t be deploying any old artifacts, they are not needed) For example,

  • cd /flexdeploy/artifacts

  • tar -czvf /app/backup/flexdeploy_artifacts_prod.tar.gz *

• Take backup of plugins folder using tar/zip commands on Production FlexDeploy

  database

  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 *

• Take backup of vsm folder (InfluxDB)

  • cd /flexdeploy/application/

    artifacts

    vsm

  • tar -czvf /app/backup/flexdeploy_

    artifacts

    vsm_prod.tar.gz *

• Make sure Test FlexDeploy is now stopped for import process

  .Copy fd_bkup.dmp file on to Test FlexDeploy database server in to data pump directory, for example - C:\oraclexe\app\oracle\admin\XE\dpdump

  .

• Import data in to target FlexDeploy database. Make sure to run this on Test environment only.

  • You will be prompted to enter password for system user. You must delete FD,FF,FD_ADMIN users from Test environment before starting import process. If necessary take backup of Test FlexDeploy database prior to starting this process.

    Run the following sql command for the appropriate database that will generate many drop table, view and procedure statements as output.  Once this sql is complete, copy all of the output and execute that against the test database.  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

    Code Block
    language sql
    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') union all select 'drop procedure ' || owner || '.' || object_name || ';' from dba_objects where owner in ('FD','FD_ADMIN','FF') and object_type = 'PROCEDURE';

PostgreSQL DB: Drop tables, views and procedures without dropping user

select 'drop table ' || table_schema ||'.' || table_name || ' cascade ;' from information_schema.tables where upper(table_schema) in ('FD','FD_ADMIN','FF') and table_type = 'BASE TABLE'
union all
select 'drop view ' || table_schema ||'.' || table_name || ' cascade ;' from information_schema.tables where upper(table_schema) in ('FD','FD_ADMIN','FF') and table_type = 'VIEW''

...

• Make sure there are no errors in import process. If there are errors, make corrections appropriately and restart import process.

...

...

impdp system directory=DATA_PUMP_DIR dumpfile=fd_bkup.dmp schemas=FD,FF,FD_ADMIN

• At this point, the Test FlexDeploy database should be copy of Production database.

• Copy artifacts zip file to Test FlexDeploy server and extract it in the artifact repository folder. You can determine Artifact Repository folder by looking at flexagon.fd.repository.root system property on server command line. Make sure to run this on Test environment only.
  

  • cd /flexdeploy/artifacts

  • tar -czvf /app/backup/flexdeploy_artifacts_test.tar.gz *

  • rm -rf *

  • tar -xzvf /app/backup/flexdeploy_artifacts_prod.tar.gz

• Now FlexDeploy artifact repository is also copied.

• Copy plugins tar/zip file to Test 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

• Now FlexDeploy plugins are also copied.

Copy Influx DB

To sync your influx db between prod and test, follow these steps:

In TEST (Target)

1. cd /flexdeploy/application/vsm

2. tar -czvf /app/backup/flexdeploy_vsm_test.tar.gz *

3. rm -rf ./*

4. tar -xzvf /app/backup/flexdeploy_vsm_prod.tar.gz

• Now FlexDeploy InfluxDB data is also copied.

Update Target Database as Necessary

• Now make various updates to make sure to limit access to the FlexDeploy Test environment and limit what FlexDeploy Test can do against various endpoints. You can customize any of these steps as per your needs. Make sure to run this on Test environment only.
  

  • Disable external realm and users, so access to FlexDeploy is very limited. Update SQL as appropriate for your setup. For example,

    Code Blocklanguagesqltheme

    RDarktitle

    Inactivate Security Setup to restrict access

    Code Block
    language sql
    update fdFD.fdFD_realmREALM set is_active='N'; update fdFD.fdFD_userUSER set is_active='N' where local_user='N'; -- update as appropriate commit;

    
    

  • Disable all endpoints, so Test FlexDeploy can not run any executions until Administrator explicitly enables some endpoints. Update base directory to not conflict in case when one of these Endpoints is enabled in Test FlexDeploy. For example,

    Update Endpoints for Test environment

    Code Block
    language sql theme RDark title Update Endpoints for Test environment
    update fdFD.endpointENDPOINT set is_active='N' where connection_type='SSH'; update fdFD.endpointENDPOINT set base_directory = base_directory || 'fdtest'; commit;

    Delete all Continuous Integration triggers.

    
    

  • If you have workflows that perform tags on Source Control Systems, make sure to update the workflows before running builds, so you do not conflict with tags created by Production FlexDeploy. You can do this by simply running this SQL also. Adjust according to your requirements.

    Update version syntax

    Code Block
    language sql theme RDark title Delete CI Triggers
    update FD.PROJECT_STREAM set version_syntax = version_syntax || ' + ".fdtest"'; commit;

    
    

  • Delete all Continuous Integration triggers.

    Delete CI Triggers

    Code Block
    language sql
    delete from fdFD.projectPROJECT_triggerTRIGGER_configCONFIG; delete from fdFD.projectPROJECT_triggerTRIGGER; commit;

    
    

  • Disable production environment. so Test FlexDeploy can not run any executions even for testing against Production environment. For example,

    Disable Production environment

    Code Block
    language sql theme RDark title Disable Production environment
    update fdFD.environmentENVIRONMENT set is_active='N' where environment_code='PROD'; -- update as appropriate commit;

  • Consider if you should change or remove any Outgoing webhooks that you have setup.
    

• Now

  you can

  start Test FlexDeploy and validate it.

  • You can make necessary adjustments to Realm, User, Groups to validate setup and perform tests as necessary. This is necessary as we disabled user and realms in previous steps.

  • You can activate specific Endpoints that you want to be included in Test environment validations.

  If you have workflows that perform tags on Source Control Systems, make sure to update the workflows before running builds, so you do not conflict with tags created by Production FlexDeploy. You can do this by simply running this SQL also. Adjust according to your requirements.

  Code Block
  language sql theme RDark title Update version syntax
  update fd.project_stream set version_syntax = ' + ".fdtest"' || version_syntax; commit;

  • Update System Settings as appropriate.

    • Change FD_SERVER_BASE_URL.

    • Change SMTP_FROM_ADDRESS. This will make sure that emails are coming from different address for Test FlexDeploy.