Hello, Thanks for proposing your tried and tested configuration solution. The idea of discussion the original proposal about OFBiz configuration with environment variable stayed in my head.
In the light of your solution and with our implementation feedback (git branching configuration + env variable), and others contributors feedback, we might elaborate the best to ease configuration management. Thanks and Regards. Gil On Sun, Feb 02, 2020 at 04:40:14PM +0100, Michael Brohl wrote: > Hi everyone, > > the recent discussions reminded me of this thread again. There were a few > people who were curious how we do configuration management and deployment > (now in production for about 10 years). It is working for projects based on > releases 13, 16, 17, 18 and trunk (with either Ant or Gradle). > > Although we have our ways to maintain this as not being part of the official > OFBiz codebase, I still think it is a good approach worth contributing. > > Is this interesting for the community? > > If there is significant interest I would try to re-write the proposal I did > in [1], updated to the newest Gradle mechanism and several aspects for multi > stage projects. > > Cheers, > > Michael Brohl > > ecomify GmbH - www.ecomify.de > > > [1] > https://lists.apache.org/thread.html/b95e239250880d9a5b34268b3b711f0f8f7f0540a26bb41c5ced493a@1213087551@%3Cdev.ofbiz.apache.org%3E > > > Am 17.11.17 um 22:18 schrieb Michael Brohl: > > Hi Jacques, > > > > it takes some effort to make an OFBiz standard compatible patch of the > > mechanism because we have several additions to the configurations. I > > would take the effort if the community wants to adapt it but it's too > > much work for just giving an idea. > > > > I have explained the mechanism in [1]. There it is based on Ant but we > > already use it in projects with Gradle. > > > > We were looking for other solutions during the migration to Gradle but > > haven't found a better approach considering all pros and cons (database > > configuration, environment variables etc.). We use it for years on our > > test- and production environments and it makes the handling of different > > system specific configurations very easy. > > > > We are thinking about the introduction of an additional configuration > > level so that we have the base configuration (containing all > > properties), a project configuration level and the system specific > > configurations. This helps us to additionally maintain projects using > > different sets of plugins. > > > > I'm happy to explain more if something is unclear. > > > > Regards, > > > > Michael > > > > > > [1] > > https://lists.apache.org/thread.html/b95e239250880d9a5b34268b3b711f0f8f7f0540a26bb41c5ced493a@1213087551@%3Cdev.ofbiz.apache.org%3E > > > > > > Am 03.11.17 um 11:39 schrieb Jacques Le Roux: > > > That's quite interesting Michael, > > > > > > Would you share in a Jira? Then we could get to merge all > > > experiences and find a consensu. > > > > > > Jacques > > > > > > > > > Le 03/11/2017 à 10:10, Michael Brohl a écrit : > > > > Just an update triggered by the question from Swapnil [1]: our > > > > configuration mechanism mentioned below is now on Gradle so it > > > > would be compatible with 16.11 and later. > > > > > > > > Regards, > > > > > > > > Michael > > > > > > > > [1] > > > > https://lists.apache.org/thread.html/703f3e615a93a2a83fb92b122eb8275fb05aa27537d95342815dd043@%3Cdev.ofbiz.apache.org%3E > > > > > > > > > > > > Am 05.07.17 um 17:56 schrieb Michael Brohl: > > > > > Hi Gil, > > > > > > > > > > we have similar challenges and modified OFBiz to deal with > > > > > it easily. We offered to contribute this long time ago > > > > > (2008) but it was decided against [1]. It was suggested to > > > > > use patches instead but I think it's too complicated to > > > > > manage several patch sets for different environments. > > > > > > > > > > We now use a staged configure mechanism which uses a base > > > > > build file, auto detected machine name and provided > > > > > parameters to decide which configurations should be pulled > > > > > for the environment. It's currently Ant based and therefore > > > > > does not fit into the current build mechanism (on the todo > > > > > list). > > > > > > > > > > I like your approach also and I think it should be evaluated > > > > > and discussed. > > > > > > > > > > Best regards, > > > > > > > > > > Michael Brohl > > > > > ecomify GmbH > > > > > www.ecomify.de > > > > > > > > > > [1] > > > > > https://lists.apache.org/thread.html/b95e239250880d9a5b34268b3b711f0f8f7f0540a26bb41c5ced493a@1213087551@%3Cdev.ofbiz.apache.org%3E > > > > > > > > > > > > > > > > > > > > Am 05.07.17 um 17:36 schrieb gil portenseigne: > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
signature.asc
Description: PGP signature
