[ubuntu-ar] Script para copiar carpeta y excluir archivos.

Mariano Mara marplatense at ubuntu.com
Thu Apr 23 16:46:35 BST 2009


On 23.04.09 11:32, Nicolas Machado wrote:
>    Mariano Mara escribió:
> 
> On 23.04.09 10:10, Nicolas Machado wrote:
> 
> 
>    buenos dias, soy algo nuevo en linux y mas en shell scripts.
>    En una misma maquina tenemos un sitio PHP en lo que llamamos desarrollo
>    y en otro httpdocs esta lo que llamamos produccion.
>    necesito un script shell que me permita copiar desde desarrollo a
>    produccion, pero
>    que:
>        Controle la fecha y si el de destino es mas nuevo , no lo copie
>        que tampoco copie archivos de configuracion. (son dos el de la conf
>    de bd y otro mas general )
>    Alguien tiene algun ejemplo que me pueda servir de base?
>    Los archivos son .php, imagenes, y alguno otro
>    Muchas gracias
>    Nicolas
> 
> 
> Deberías usar un sistema de control de version para esas cosas donde
> puedas ignorar archivos y se encargue por vos de pasar las
> modificaciones. Hay muchisimos dando vueltas, yo te recomiendo bzr[1]
> 
> Mariano
> 
> [1] [1]http://bazaar-vcs.org/
> 
> 
>    Ante todo gracias Mariano.
>    La duda que siempre tuve con los CVS, y por eso no lo uso, es la
>    siguiente:
>    En el caso de una aplicacion php uno esta desarrollando sobre el sitio
>    directamente, es decir cambio el php, F5 en el browser y ya veo el
>    cambio.
>    si tengo q crear mi propio directorio con todos los php de la
>    aplicacion estaria duplicando el sitio, creo.
>    Si ademas somos 2 los desarrolladores, estamos triplicando el sitio.
>    y si ademas tengo un entorno que llamo produccion, lo estoy
>    cuadruplicando.
>    teniendo en cuenta que el sitio YA esta creado, cual seria la mejor
>    manera de ahora que esta "listo" y en la version 1.0, cargarlo a un CVS
>    ?
>    incluso habia pensado en que el repositorio estuviera en internet, pero
>    no me cerrabala idea de tener el sitio en cada usuario .
>    Es asi como deberia trabajar ?
>    Alguna sugerencia ?
>    Saludos
>    y gracias
> 
> References
> 
>    1. http://bazaar-vcs.org/

La idea que esté duplicado no es mala (no creo que pese gigas): tenés
copias de respaldo como plan de contención. 

Vamos a hacer dos cosas: te voy a proponer un modelo de trabajo para que
sigas usando el workflow que tenés definido hoy en día y además te voy a
proponer otro que yo veo como ideal y te voy a dar algunos ejemplos de
donde tenés ventajas si usás el que te propongo.

1- Tu workflow actual pero con versionado:
Tu carpeta desarrollo es tu mainline de trabajo (la vamos a llamar
trunk) y es tu objetivo principal de trabajo.
Para versionarla con bzr [1] simplemente te parás en el raíz del trunk y
hacés
bzr init
luego deberás agregar los archivos y hacer el commit inicial (te dejo los
detalles para que los investigues en los docs de bzr: son muy simples).
Allí también podrás "ignorar" archivos (o sea que no se versionen).
Luego te vas a tu sitio de producción y hacés que sea una copia de tu
trunk (no una copia por linea de comandos, una copia por ejemplo con el
comando branch que solo va a copiar los archivos que vos hayas agregado
y no los que ignores).
Estaría listo: cada vez que hagas algo en tu trunk, le das commit (eso
te va a permitir recuperar cosas anteriores si es necesario, por
ejemplo) y cada vez que tengas algo listo para producción, te vas a la
carpeta de producción, hacés un pull (o sea que traiga los cambios) y en
tu sitio de producción solo vas a recibir las diferencias de los
archivos que hayas cambiado y nada más (si esos cambios son de archivos
que no estén ignorados).
Ahí tenés tus dos pedidos originales respondidos y además tenés un
historico de todos tus cambios por si los necesitás y no tocaste casi
nada de como venís haciendo las cosas hoy en día.

2- Ahora vamos a un escenario más completo:

* en la máquina de cada desarrollador tengo todo lo necesario para
replicar el ambiente donde corre mi aplicación (un apache, un php
completo, una base de datos con los datos de ejemplo o mejor aún una
conexión remota a la base donde están los datos de ejemplo).
* hago bzr init en mi servidor de desarrollo (como el paso anterior) y
desde la máquina de cada desarrollador hago un branch y tengo una
copia en local: yo desarrollador me hago "otra" copia de ese trunk y
trabajo exclusivamente ahí. Cada vez que tengo algo que quiero que el
resto vea o que considero que está listo para subirse, lo paso a mi
"trunk" local y subo esos cambios al servidor de desarrollo. A partir de
ese momento ese cambio está disponible para todos (incluido el servidor
de producción donde aplicarían los pasos que te comenté anteriormente).
¿Qué ganas vos con todo este despliegue?
a- si te levantaste cruzado un día y muy poco inspirado te ponés a
desarrollar y por esas casualidades haces alguna estupidez, no afectás
ni el repositorio central ni el sitio de producción, solo tu versión.
b- tenés copia de respaldo del desarrollo: ya se puede prender fuego el
servidor y todos tus compañeros pueden desaparecer, vos seguís teniendo
una copia de todo el trabajo y te reís de janeiro.
c- ponele que tenés mucho tiempo libre porque no hay nada para hacer y
ya te aburriste de jugar al arkanoyd, el buble buble o alguno de esos
juegos modernos que tienen ustedes los jovenes y finalmente vas a
ponerte a hacer ese nice-to-have que alguna vez te pidieron pero como
era muy poco crítico no lo hacías: hacer un branch, te ponés a trabajar
y justo que estás haciendolo llega un bug crítico que si o si hay que
arreglar ahora: jamaica don't worry, te hacés otro branch de tu trunk
(total los cambios que estabas haciendo no estaban ahí), arreglás el
bug, subís el código  a tu copia local del trunk, lo subís al servidor y
de ahí a producción. Tu branch con el nice to have sigue donde lo
dejaste y no afectó tu trabajo.

¿Es más trabajo? Seguro
¿Vas a tener más copias? Seguro (aunque podés tener un shared repo donde
se comparte el árbol de cambio).
Pero al final del día vas a trabajar más tranquilo y te vas a ahorrar
muchos dolores de cabeza que seguro tenés con tu workflow actual de
trabajo (archivos pisados, cambios que no deberías haber hecho, cosas
que te pisaste con otro desarrollador).

Espero que esta guía a las apuradas te sirva como respuesta.
Suerte con eso.

[1] te hago el ejemplo con bzr pero hay muchos otros dando vueltas, vos
comparalos y elegí el que te vaya mejor:
http://en.wikipedia.org/wiki/Comparison_of_revision_control_software




More information about the Ubuntu-ar mailing list