Re: capistrano deployments w/ wo
Re: capistrano deployments w/ wo
- Subject: Re: capistrano deployments w/ wo
- From: "Michael Bushkov" <email@hidden>
- Date: Wed, 19 Nov 2008 10:06:33 +0300
Hi Lachlan,
On Tue, Nov 18, 2008 at 11:08 PM, Lachlan Deck <email@hidden> wrote:
> Hi Michael,
>
> On 18/11/2008, at 10:46 PM, Michael Bushkov wrote:
>
>> I've posted some initial information here:
>>
>> http://wiki.objectstyle.org/confluence/display/WO/Web+Applications-Deployment-Capistrano+(Overview)
>>
>> This is some kind of overview/beginner's guide. There are 2 things to go:
>> * I'll write about advanced usage techniques.
>> * I'll publish my sources that can be interesting to the community.
>>
>> I hope to do both of these things in 2-3 days.
>
> That's great. I've got some suggestions.
>
> There's an assumption in the guide that the currently deployed apps are not
> actively running and are just 'rm -rf ...' even prior to 'deploying' (i.e.,
> copying up) the new build. I know this is a beginner's guide - but this
> seems like not so good advice even for newbies as (at least for normal
> deployments) it provides no option to roll back.
Yes, maybe I simplified things too much. I'll add backup creation and
rollback to this example.
>
> So here's some ideas for bonus points .. at least for the advanced guide.
> It'll be good to see (if not in your immediate plans) versioning used when
> deploying which includes auto-injecting into JavaMonitor (or similar) the
> new deployments without pulling down the old ones. So there'll need to be
> *.cap tasks for
> - putting up a new version of an app (which doesn't overwrite an old one)
> - starting up the new instance(s)
> - setting the old instances to refuse new sessions
> - removing apps
> - if rsync is used you can upload to current app if only fixing a resource
> for example.
> - dealing with split installs (keeping versioning in mind)
>
> :-)
Wow, that sounds impressive ) Do you use this model of deployment?
Actually we have a bit different approach:
* We upload new version of the app to the server to the [special
folder]/[app name]/[revision number] path.
* Then we make a soft link from there to
/Library/WebObjects/Applications/[app name]. After that the previous
deployed version still exists - but not in
/Library/WebObjects/Applications
* After that we send restart command to monitor and the app restarts.
It results in small downtime, but If the downtime is not acceptable,
we restart app manually (instance by instance) in JavaMonitor.
This is quite a simple approach, it doesn't require a lot of
integration with JavaMonitor or wotaskd and works quite well for us
right now. The plan, that you're proposing sounds good too (much more
complicated, though ;) ) - I guess I can write Capistrano recipes for
missing parts. By the way, just interesting, do you use test/build
server or do you deploy straight from your development machine?
>
> with regards,
> --
>
> Lachlan Deck
>
>
--
With best regards,
Michael Bushkov
_______________________________________________
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