On Wed, Apr 21, 2010 at 8:13 PM, Les Mikesell <lesmikesell_at_gmail.com> wrote:
> On 4/21/2010 8:48 AM, Vikrama Sanjeeva wrote:
>
>>
>>
>
>> Also, in case of web-applications what is the best practice to
>> deploy REL-1.7 on production ? Do we replace whole REL-1.6 code
>> with REL-1.7 or just update the production with modified
>> binaries of REL1.7 ?
>>
>>
>> Normally you would want to work in a way that gives you a known
>> 'roll-back' state in case the next change introduces problems. If
>> you don't keep a whole release together you'll have to track the
>> individual changes to know how to reproduce the last working state.
>>
>>
>> So you actually mean that for every change (big in size like 5-10+
>> files) whole code should be replaced with new release, while keeping an
>> option of "roll-back" ?
>>
>
> There are different tradeoffs depending on how the application works and
> where you need to deploy, but a good arrangement is to have a 'staging'
> server where you can update or switch to a release tag and execute/test
> directly from the workspace, then use a scripted 'rsync -C ...' type of
> command to propagate to the production server(s). Rsync is smart enough to
> (a) only copy the changes and (b) receive under a different name, renaming
> only when the transfer is complete and successful. If you never make
> changes in the staging workspace you guarantee that what you test and push
> to production is a reproducible copy from the subversion repository that you
> can recall if you need to revert to that version later.
>
> --
> Les Mikesell
> lesmikesell_at_gmail.com
>
Agreed. We do use staging for testing and UAT with client and if all works
good then only planned deployment is done on production. However, I like
your idea of "rsync -C.." command for deploying "accurate" changes from
staging to production. But I think in this case, deployment engineer should
be confident that only change related to a specific feature is present on
staging and ready to ship on production. Because, if there are multiple
features residing in staging but only certain features qualifies for
production then running "rsync -C..." will be expensive.
Bye,
Viki,
Received on 2010-04-22 01:21:59 CEST