Posted by
cjhowe on
Mar 29, 2006; 4:58pm
URL: http://ofbiz.116.s1.nabble.com/Users-Configuration-management-tp138197p138204.html
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-775It 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/users