Ruby Forum Rails-ES > cap deploy sólo de los cambios ó modi ficaciones

Hola gente,

Igual me paso de novatada, pero me surge una duda y no encuentro nada
en google o no sé como preguntar.

Me gustaría hacer 'deploys' de mi aplicación usando capistrano pero
que no se descargue todo el repositorio sino que solamente actualice
los cambios en referente a su copia actual.

Ya sé que no podré hacer un rollback, pero no es lo que necesito
ahora, tengo un repositorio muy pesado y un svn con poco ancho de
banda y me da pereza que por un cambio de nada tarde 10 minutos en
hacer un 'cap deploy'.

Si no existe nada parecido.. pues para intentar hacerlo yo.. que
todavía no he tocado capistrano.

Gracias
f.

Usa la estrategia "remote_cache". Lo que hace es mantener una cache del
código fuente, entonces en cada deploy lo que hace es actualizar esa
cache y luego copia los ficheros localmente.

En tu deploy.rb debes poner:

set :deploy_via, :remote_cache
set :repository_cache, "repository_cache/"          #Opcional si no lo
mete en cached-copy.




Fernando Guillen escribió:

¿Tienes recursos como imágenes o datos que podrías sacar del control de
versiones para aligerar esos deploys?

De todas maneras ten en cuenta que siempre podrás escribir tus propias
tareas o redefinir las que trae por defecto para que en lugar de hacer
un export y te monte todo el tema de los enlaces simbólicos hacer un
simple update, aunque en ese caso evita a toda costa luego hacer cambios
a mano en la máquina de producción para que el subversion no te de
ningún conflicto.

Saludos.

Fernando Guillen wrote:
> ahora, tengo un repositorio muy pesado y un svn con poco ancho de
> banda y me da pereza que por un cambio de nada tarde 10 minutos en
> hacer un 'cap deploy'.
>
> Si no existe nada parecido.. pues para intentar hacerlo yo.. que
> todavía no he tocado capistrano.
>
> Gracias
> f.
>
>   


--
/**
 * dagi3d v4 | http://dagi3d.net
 */

2008/8/8 Rafael G. <rgo@aspgems.com>:
> Usa la estrategia "remote_cache". Lo que hace es mantener una cache del
> código fuente, entonces en cada deploy lo que hace es actualizar esa cache y
> luego copia los ficheros localmente.
>
> En tu deploy.rb debes poner:
>
> set :deploy_via, :remote_cache
> set :repository_cache, "repository_cache/"          #Opcional si no lo mete
> en cached-copy.

Gracias Rafael,

Soluciona perfectamente mi problema :)

Perdona la tardanza en contestar, he estado desconectado el fin de 
semana.

Saludos
f.

El día 8 de agosto de 2008 19:12, Borja Martín <borjam@dagi3d.net> 
escribió:> ¿Tienes recursos como imágenes o datos que podrías sacar del control de
> versiones para aligerar esos deploys?

Tengo 8 megas de imágenes y 11 megas de javascript :)

Experimentos :)

Pero, no, no los puedo sacar del repositorio.

>
> De todas maneras ten en cuenta que siempre podrás escribir tus propias
> tareas o redefinir las que trae por defecto para que en lugar de hacer
> un export y te monte todo el tema de los enlaces simbólicos hacer un
> simple update, aunque en ese caso evita a toda costa luego hacer cambios
> a mano en la máquina de producción para que el subversion no te de
> ningún conflicto.

Claro, es lo que pensaba hacer si no existía nada ya hecho. No me
hubiera importado, pero si ya estaba no quería reinventar la rueda.

Gracias
f.

Nosotros estábamos acumulando muchísimo material gráfico en /doc, así 
que decidimos reestructurar el repositorio en dos directorios: /doc y
/src. No sé si te puede servir en tu caso: si configuras el servidor
para que sirva las imágenes o esos 11 megas de javascript(!!!) de un
directorio externo a /src y editas el deploy para hacer checkout del
subdirectorio /src podrás hacer deploys solamente del código de la
aplicación, manteniendo todo versionado.

El día 11 de agosto de 2008 13:24, Raul Murciano <raul@murciano.net> 
escribió:> Nosotros estábamos acumulando muchísimo material gráfico en /doc, así
> que decidimos reestructurar el repositorio en dos directorios: /doc y
> /src. No sé si te puede servir en tu caso: si configuras el servidor
> para que sirva las imágenes o esos 11 megas de javascript(!!!) de un
> directorio externo a /src y editas el deploy para hacer checkout del
> subdirectorio /src podrás hacer deploys solamente del código de la
> aplicación, manteniendo todo versionado.

Buena sugerencia.

Pero, no, no puedo sacar el javascript.. estoy en plena
experimentación y todo cambia y todo vale :).. también los 11megas de
js.. pero bueno que luego se borrarán cosas.

f.

Para cuando termines de experimentar con el javascript puedes usar JS
Min [1] para reducir el tamaño de tus jotaeses en producción al
mínimo.

Y si luego activas el gzip en el servidor web se te queda fino fino.

[1] http://www.crockford.com/javascript/jsmin.rb



2008/8/11 Fernando Guillen <fguillen.mail@gmail.com>:

El día 11 de agosto de 2008 15:13, Fernando Blat <ferblape@gmail.com> 
escribió:> Para cuando termines de experimentar con el javascript puedes usar JS
> Min [1] para reducir el tamaño de tus jotaeses en producción al
> mínimo.
>
> Y si luego activas el gzip en el servidor web se te queda fino fino.
>
> [1] http://www.crockford.com/javascript/jsmin.rb

thx

El 11 de agosto de 2008 15:13, Fernando Blat <ferblape@gmail.com> 
escribió:

> Para cuando termines de experimentar con el javascript puedes usar JS
> Min [1] para reducir el tamaño de tus jotaeses en producción al
> mínimo.


Gracias por el enlace a jsmin. He hecho unas mediciones para hacernos 
una
idea:

* prototype.js => 122,7 Kb
* prototype_min.js => 91,3 Kb (74,4 %)


>
> Y si luego activas el gzip en el servidor web se te queda fino fino.
>

Mediciones compromiendo a .zip:

* prototype.js.zip => 28,3 Kb
* prototype_min.js.zip => 23 Kb (81 %)

Más info sobre el uso de jsmin en
http://www.crockford.com/javascript/jsmin.html


>
> [1] http://www.crockford.com/javascript/jsmin.rb
>