Hi Gil and all, Faced the same issues before.
I had different environments like SIT, UAT and PROD requiring different settings. There was also specific requirements to remove the source folders and zip the final files for deployment. So I created a folder which has subfolders named after each different environment and contains the respective environment-specific properties e.g. - deployment - SIT - db.properties ... - UAT - db.properties ... Also created a set of template files that contained placeholders to be replaced during deployment - templates - entity-engine.xml ... Finally there is a custom Ant target for deployment to each environment that will: 1) build OFBiz and copy the required files (leaving out the source folders) into a build folder; 2) read the template files and replace the placeholders with the right environment properties before copy to the correct location in the build folder; and 3) zip the contents of the build folder and append a timestamp. Having said all these, your approach is convention over configuration, and keeps the environment properties separate from the OFBiz folder. So +1 from me. Regards, James Yong On 2017-07-05 23:36 (+0800), gil portenseigne <gil.portensei...@nereide.fr> wrote: > Hello all, > > Working with different hosting companies, we used to have issues when > deploying OFBiz concerning technical configuration of the different > environments. > We are writing this mail to get feedback from the community and > eventually propose to improve OFBiz on this matter. > > For a customer, we are working with 4 instances of a release 13.07 > OFBiz, and are currently using a set of patches (with addonmanager...) > to manage environment specific configurations. > During each production deployment, the hosting company receive from our > jenkins a precompiled archive containing OFBiz codebase, and then apply > the set of patches to configure it to the environment needs, recompile > and relaunch... > > This way of doing can cause issue when patch could not apply, after a > codebase modification (pretty rare but it happens). > > We are not satisfied with this way of doing, we are currently thinking > about using environment variables to configure technical environment > properties (those are on the hosting company responsibility), and to > keep functional specifics into the code base. > If you have some experience or advice in this matter, you are welcome. > > For our case, we currently have enhanced OFBiz to be able to get > environment variable from the operating system within property file and > some other configuration files (with default value if not set). > > Examples : > *In Property file : > password=${env:ONE_CONF:ofbiz} -> environment variable ONE_CONF or ofbiz > if unset > other_config=${env:OTHER_CONF:${partyId}} -> environment variable > OTHER_CONF or ${partyId} if unset > *In entityengine.xml : > jdbc-uri="${env:DB_POSTGRES_URI:jdbc:mysql://127.0.0.1/ofbiz?autoReconnect=true}" > jdbc-username="${env:DB_POSTGRES_USER:ofbiz}" > jdbc-password="${env:DB_POSTGRES_PWD:ofbiz}"/> > > That allow us to keep functional parameters stored within git branches. > Our jenkins now is able to build our 4 configured and compiled instances > and deliver it to the hosting company, that just have to set/check > environment variable (database access, activeMQ, log location, instance > id, etc.) before starting OFBiz app. Now we cannot have configuration > failure during deployment. > > We will be glad to contribute it, if it's the good way to go ! > > Best Regards ! > > Gil Portenseigne >