Re: capistrano deployments w/ wo
Re: capistrano deployments w/ wo
- Subject: Re: capistrano deployments w/ wo
- From: Lachlan Deck <email@hidden>
- Date: Fri, 21 Nov 2008 06:28:41 +1100
On 20/11/2008, at 7:33 PM, Denis Frolov wrote:
On Wed, Nov 19, 2008 at 2:29 PM, Lachlan Deck
<email@hidden> wrote:
Currently we're pulling builds from bamboo. So after each svn
commit bamboo
runs the build (maven in my case, which produces a tar.gz for both
the app
and webserver resources). We've then got shell scripts that when
manually
called pull a specific build from bamboo, rsync/unpack them to a
certain
location (whether for test or deployment environment).
In JavaMonitor for each app we define multiple instances per server
pointing
to each of 'a', 'b' (and sometimes 'c') folders for an app. So the
folder
structure is like so:
/<...>/javaMonitorAppName/a/ProjectName.woa/
/<...>/javaMonitorAppName/b/ProjectName.woa/
/<...>/javaMonitorAppName/c/ProjectName.woa/
/<...>/javaMonitorAppName/Properties/log4j.properties
/<...>/javaMonitorAppName/Properties/jdbc.properties
/<...>/javaMonitorAppName/Properties/runtime.properties
This way if we need to fire up new instances of the same version we
can
whilst killing of the old ones (e.g., if out of mem is hit).
The webserver resources are placed in a similar structure in the
relevant
location (which is defined per instance in JM). For actual static
resources
(that are simply under apache's control) we've not yet versioned
these and
our versioned split install needs some improving with css files
that have
some hard-coding included which refers to the version (as needed).
This can
be easily solved during the deployment phase by regex-replacing
certain
tokens.
What about database? Instances from 'a' would die in case of
database/data migration since database is changed upon startup of
instances from 'b'.
That would be true if, of course, instance 'b' deletes or renames
columns/tables. We just don't do that ... or leave it for a subsequent
migration (or done by hand if necessary).
Versioning of database doesn't seem to be an
option here since you will have to merge data inserted by different
instances to different databases.
This hasn't been a problem for us ... yet. We can easily drop
something from the eomodel without dumping the stuff from the db.
with regards,
--
Lachlan Deck
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden