🚀 go-pugleaf

Hola, Count:

Count Zero wrote:
> Iba "Jes�s M. NAVARRO" por es.comp.os.linux.programacion
> 
> 

[...]

> 
>>2/ Operar *siempre* contra m�dulos completos: as�, si existe el m�dulo
>>"sitio_web_1", todas las operaciones globales las llevar�s a cabo en
>>este nivel y no en niveles interiores (`cvs tag sitio_web_1`, no `cvs
>>tag sitio_web_1/fichero.txt`).  Esto permite, adem�s, el uso de un
>>"fichero sabio" que te permitir� convertir operaciones "file oriented"
>>en operaciones "module oriented" simplemente con realizarlas cuando el
>>"fichero sabio" se vea afectado.
>>
>>As�, veamos el caso pr�ctico de uso de taginfo:
>>El cuarto par�metro que se pasa al script es un "array" que contiene el
>>nombre del fichero afectado y la revisi�n: si utilizas un "fichero
>>sabio", te basta con que el script s�lo haga lo que tenga que hacer
>>cuando el nombre del fichero coincida con el del "fichero sabio",
>>teniendo en cuenta que la operaci�n "tag" (trata de evitar rtag en la
>>medida de lo posible, salvo cuando puedas asociarla a otro tag ya
> 
> 
> No he entendido muy bien esta parte, pero creo que m�s o menos �s lo que 
> ten�a pensado.
> 
> Quieres decir poner un fichero 'centinela' en el modulo para que el script 
> se fijar� s�lo en �l. 
> 

Exacto.

> Pero si �s as� hay un problemilla. Supongamos que la �ltima revision de 
> todo el m�dula ya est� etiquetado como 'prod' (la etiqueta que busca el 
> script en el centinela). Modifico un fichero y hago un cvs tag -F prod. 
> C�mo s�lo hay un archivo (el modificado) que no tenga el tag CVS s�lo har� 
> tag sobre este. O sea que deber�a modificar cada vez el centinela para 
> 'activar' el script. Espero explicarme bien.
> 

Si todo el m�dulo est� en estado 'prod' es que es un m�dulo de 
producci�n ;^D
En realidad, hasta ahora, yo *s�* alteraba el fichero "centinela", 
porque lo usaba para procesar m�s informaci�n, de forma que sab�a que 
siempre ten�a que cambiar (concretamente, se ten�a que a�adir a �l una 
l�nea indicando qu� "petici�n de cambio" se completaba a la hora del 
checkin).  Sin embargo *creo* (pero tendr�s que comprobarlo) que si 
haces `cvs tag -F prod nombre_modulo`, disparar�s la acci�n de taginfo 
contra tu fichero de cambio, incluso si su �ltima revisi�n tiene ya el 
tag "prod".

En mi caso el flujo de trabajo iba m�s o menos como sigue:
1/ El responsable del proyecto acepta una "petici�n de cambio" a la que 
se da un identificador (la idea era "incrustar" este proceso en una 
herramienta tipo gnats o bugzilla, aunque esto no llegu� a 
implementarlo), digamos, 'cs_123' (por "ChangeSet n�mero 123") y se 
asigna a un responsable.  El responsable, estudia la petici�n y le 
asigna los recursos que cree necesarios (puede resolverlo el mismo, 
puede requerir la ayuda de otros programadores, o incluso puede requerir 
que se completen tareas fuera del �mbito de la programaci�n, como 
conseguir aprobaci�n por parte del cliente, por ejemplo).  En funci�n de 
lo complejo del caso, puede ser necesario o no crear una rama en el 
m�dulo (que se llamar�a br_cs_123, por BRanch para el ChangeSet n�mero 
123).  En todo caso, cuando se considera que se ha completado el proceso 
de desarrollo, al "fichero centinela" se a�ade una nueva l�nea, m�s o 
menos como sigue:

cs_123: completed

As�, el fichero de centinela ha cambiado, el cambio se env�a al 
repositorio y a todo esto se aplica el tag cs_123; esta aplicaci�n del 
tag dispara el script correspondiente a trav�s de taginfo que, entre 
otras cosas, en mi caso, actualizaba autom�ticamente un servidor web 
"staging" con los nuevos contenidos.

Una vez que los contenidos eran revisados y aceptados, en principio, por 
el responsable del proyecto, �ste induce un nuevo cambio en el fichero 
centinela, de forma que la l�nea anterior pasa a ser

cs_123: approved

Por la noche, un proceso arrancado desde cron, realizaba un proceso que, 
entre otras cosas inclu�a lo siguiente:
1/ Generaba una sandbox a partir del tag "last_stable" (cvs co -r 
last_stable nombre_modulo deb�a ser el comando, poco m�s o menos)

2/ Se obtiene la �ltima versi�n del fichero centinela (cvs update -A 
fichero_centinela).  En este fichero se buscan las l�neas que contienen 
tags en estado "approved", y se actualiza el sandbox sucesivamente a 
este nivel (cvs update -rNombreTag nombre_modulo).  Como ejemplo, el 
fichero podr�a contener lo siguiente:

cs_78: approved
cs_124: completed
cs_123: approved

Entonces, el script extraer�a por last_stable, luego a�adir�a los 
cambios por el tag cs_123 y luego los correspondientes a cs_78 (como 
est� m�s alto en el fichero, eso significa que se cerr� m�s tarde).  La 
sandbox en su estado actual es equivalente a la nueva versi�n de 
producci�n deseada (equivalente, no id�ntica, ya que esta sandbox puede 
requerir de variado "masajeo" -la fase de "building"- antes de ser 
id�ntica a lo que deseamos en producci�n: puede ser necesario, por 
ejemplo, ignorar cierto fichero de configuraci�n, o editarlo para que 
los datos de login/password inclu�dos sean los correctos, o cambiar de 
sitio alg�n fichero porque el layout en desarrollo no es exactamente el 
mismo que el del entorno de producci�n, o lo que sea).  Pues eso: se 
procede a la fase de "build" y se actualizan por el procedimiento que 
sea los datos al servidor de producci�n (normalmente utilizando rsync 
sobre ssh, con el concurso o no de alg�n otro script en el propio 
servidor de producci�n).

Finalmente, si todo ha ido con �xito, se borran las l�neas con changeset 
en estado "approved" que ya se hayan aplicado a producci�n y se "empuja" 
el tag "last_stable" a la posici�n actual.

De nuevo, �ste es el proceso "m�s o menos", para que te hagas una idea: 
los detalles concretos de la implementaci�n, quedan para t� ;^P
-- 
SALUD,
Jes�s
***
jesus_navarro@undominio.net
***