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
Received on 2010-04-21 19:13:52 CEST