http://ofbiz.116.s1.nabble.com/Users-Configuration-management-tp138197p138205.html
instances of OFBiz on the same box for testing, and even production.
other configuration files could be stored in a database table.
page depending on the request's header ie.
> Along with patching in the local environment, creating
> this improvement in Jira might make it easier for
> updating this scenario...
>
>
http://jira.undersunconsulting.com/browse/OFBIZ-775>
> It focuses on making the configuration files that are
> actually used (config.xml) not be under version
> control, but rather have a template (config.tmpl) be
> under version control. Then in the build routine, if
> the configuration file does not exist, have
> config.tmpl be copied to config.xml so that the
> default scenario will exist.
>
>
> =========David Jones wrote:
> Ben,
>
> In general there shouldn't be any such references in
> code (and if there are they should be fixed...). This
> still leaves a fun mix of configuration files to deal
> with and for those I usually recommend just using
> patches for each deployment.
>
> We run into this a fair amount with larger deployments
> of multiple instances of OFBiz. I've mostly worked
> with this in a server farm environment, but the same
> pattern would apply to running multiple instances on
> the same box.
>
> The general idea is to have no manual editing of
> anything in the deployment process. This improves
> reliability quite a bit, especially in production
> environments where you generally want to keep the
> deployment process as simple as possible and have
> everything come straight from your code repository.
> This makes it easier and less error prone to test a
> deployment candidate, and if something does happen it
> is easier to track down and fix, and in the mean time
> back up to and deploy a previous revision.
>
> This would involve a set of patches for each target
> system. Sometimes if certain deployments have more
> variations it is helpful to have branches in your
> local SVN repository (or whatever you are using) that
> can be synchronized as needed and deployed from there.
>
> Usually the patches would include one for each test,
> staging, and production deployment. It depends a lot
> on what your environment is like of course. In most
> cases development deployments are the "no patch"
> settings and these are mostly run locally on
> developers machines. OFBiz runs fine on plain old (but
> modern...) desktops and for development that is the
> way to go.
>
> -David
>
>
>
> Benjamin Cox wrote:
> > Folks,
> >
> > I'm curious about what people are doing for
> configuration
> > management? For instance, deployment and/or
> development to different
> > IPs, ports, etc. all on the same box, or spread
> across different
> > machines. We're setting up to do ofbiz development,
> and work with
> > multiple developers on a single beefy box. In
> addition, we would
> > like to, say, run regression tests on the same box
> while developing
> > (hey, it's beefy). Either of these requires some
> means of keeping
> > things separated, such that we don't conflict with
> one another.
> >
> > This brings up the issue of maintaining many
> separate files with the
> > same set of IP or port values used in them. There
> are quite a few
> > files in which a clean checkout of ofbiz currently
> has either
> > "localhost", "127.0.0.1", or "8080" in them. If we
> do this for our
> > situation, this would means that a developer must
> change several
> > files after checking out, and remember not to commit
> those changes
> > back to our local repository. Likewise, when
> deploying to a
> > production environment, those values may have to be
> changed, possibly
> > with different values for various components in a
> high-volume setting.
> >
> > My question is how do people deal with different
> configurations of
> > host and port, database parameters, etc. today? Is
> there some single
> > change point that controls all others? Perhaps
> variables or
> > properties resolvers so I can use a $primaryHost
> variable in several
> > files, rather than "hard-coding" localhost into all
> of those files?
> >
> > Or does everyone just use localhost:8080 for
> everywhere?
> >
> > Any insight will be deeply appreciated,
> >
> > Ben
> >
>
> _______________________________________________
> Users mailing list
>
[hidden email]
>
http://lists.ofbiz.org/mailman/listinfo/users14150 NE 20th St. Suite F1