Best practice in regards to creating environment specific constants

RE: Best practice in regards to creating environment specific constants

erickp — Thu, 21 Mar 2019 23:16:13 GMT

Good question Kevin. When we refresh from production to DEV, we are not exporting from production and importing back to DEV. I realize that if we were to do that, the environment specific functionality in constants (and other objects) would work just fine. We are basically taking a snapshot of the KDBs from production and moving them into DEV. We are copying kdbs from a nightly backup and copying into DEV, along with a matching database backup and copy of data from accdocs1, accdocs2 etc. Because we are copying the kdbs and not importing the applications, the environment specific process doesn't work for us. I hope this makes sense.

RE: Best practice in regards to creating environment specific constants

Kevin Gajewski — Thu, 21 Mar 2019 22:37:22 GMT

Can you clarify what you mean by "...when we refresh from production to DEV"? Are you exporting your apps from production and importing them back to development? Are you snapshotting your entire system (engines and all) and using that?

RE: Best practice in regards to creating environment specific constants

Mike Schmitt — Thu, 21 Mar 2019 17:51:50 GMT

> This doesn't help me because when we refresh from production to DEV, for example, the constant value in DEV will be updated with production value.

That's not how environment-specific constants work. If you try this out for yourself, you will find that this functionality has been intentionally set up such that it does not overwrite the constant's current value in the current environment even when importing the constant with a different value from another environment. A better way to think of it is, the exported version doesn't actually carry a value, so that for new imports you need to use the .properties file at least the first time to set it initially.

RE: Best practice in regards to creating environment specific constants

erickp — Thu, 21 Mar 2019 17:20:15 GMT

I had read that before but that is not exactly what I am looking for. My understanding was that import customization file was used just during the deployment process if, for example, a constant in DEV is = 1 but I want when the deployment to QA finishes, for the value to be updated to 2. This doesn't help me because when we refresh from production to DEV, for example, the constant value in DEV will be updated with production value. Or am I wrong?

RE: Best practice in regards to creating environment specific constants

Tim — Thu, 21 Mar 2019 17:16:15 GMT

Have a look at the import customisation help pages: docs.appian.com/.../Application_Deployment_Guidelines.html

and docs.appian.com/.../Application_Deployment_Guidelines.html