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
>
