Agreed, if you can switch to Cap that'd be best.
That being said, pre-capistrano we did the following:
- *Initial checkout:*
- All releases were checked out from svn/git to a directory with release
information in the path so.... /home/deploy/application-rc-1.2
- This was soft linked to the production directory
/home/deploy/application
- *New release:*
- Same thing, check out from svn/git to a directory with the full
release information*...* /home/deploy/application-rc.1.3
- Remove previous softlink and relink to new checkout. Restart
application server.
- *Roll back*:
- Do it in reverse...
- Remove previous softlink and relink to last checkout. Restart
application server.
While the checkouts take a bit longer this way.... being able to roll back
immediately made it worth it.
On Fri, Jan 15, 2010 at 9:38 AM, Matt Aimonetti <[email protected]>wrote:
> Wow, I agree with both Nick and Patrick... something much be wrong with me
> ;)
>
> I agree with Patrick that in general you should stick to standard tools
> like cap (or vlad). However cap isn't always very efficient and it might not
> be able to do something very specific you have to do. If that's the case,
> using a simpler solution like a custom git based solution can be very cool.
>
> However in this very specific case you probably won't the only one having
> to deal with deployment, in the future, another contractor might have to
> work on the code. If I were you, I'd be kind and not use some home made
> deployment solution that only you understand, unless you want to force the
> client to depend on you ;)
>
> - Matt
>
>
>
> On Fri, Jan 15, 2010 at 8:06 AM, Patrick Crowley <[email protected]>wrote:
>
>> > Anyone do the syncing thing rather than Capistrano? Do you do anything,
>> maybe with Git, to be ready to roll back and sync the last known working
>> version of the code?
>>
>> Unless there is specific technical reason to not use Capistrano (which I
>> doubt), I'd strongly recommend your client switch over to Cap. (Vlad is a
>> good option too.)
>>
>> The roll-your-own-deploy-script-with-rsync-and-ruby approach seems ripe
>> for failure.
>>
>> -- Patrick
>>
>> --
>> SD Ruby mailing list
>> [email protected]
>> http://groups.google.com/group/sdruby
>>
>
>
> --
> SD Ruby mailing list
> [email protected]
> http://groups.google.com/group/sdruby
>
--
SD Ruby mailing list
[email protected]
http://groups.google.com/group/sdruby
