• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: capistrano deployments w/ wo
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


References: 
 >capistrano deployments w/ wo (From: Mike Schrag <email@hidden>)
 >Re: capistrano deployments w/ wo (From: "Michael Bushkov" <email@hidden>)
 >Re: capistrano deployments w/ wo (From: Mike Schrag <email@hidden>)
 >Re: capistrano deployments w/ wo (From: "Michael Bushkov" <email@hidden>)
 >Re: capistrano deployments w/ wo (From: Lachlan Deck <email@hidden>)
 >Re: capistrano deployments w/ wo (From: "Michael Bushkov" <email@hidden>)
 >Re: capistrano deployments w/ wo (From: Lachlan Deck <email@hidden>)
 >Re: capistrano deployments w/ wo (From: "Denis Frolov" <email@hidden>)

  • Prev by Date: Re: Non Responsive WO APPS
  • Next by Date: ThumbnailMaker.java
  • Previous by thread: Re: capistrano deployments w/ wo
  • Next by thread: Spell Check with WebObjects [Bug in ERXGoogleSpell API]
  • Index(es):
    • Date
    • Thread