[opensuse-es] Automatización de SCM
Hola a tod@s: Lamento haberme vuelto tan disperso con ésto (llevo 4 hilos con diferentes títulos y buscando una solución a lo mismo), pero es que según concluyo, no se me ha dado la información clara, precisa y concisa. Reproduzco el escenario y la intención final: Existe un par de redes: una para entorno de desarrollo/pruebas y otra para producción. Hay un grupo de programadores que tienen acceso a las dos redes ... y no se pueden restringir del acceso a la red de producción. Los males surgen cuando los programadores descargan la copia del repositorio (de pruebas o de producción, no tengo claridad en ésto) a su computadora para trabajar y luego (algunos de ellos) olvidan actualizar el repositorio con su trabajo recién hecho. Al final (ha ocurrido varias veces), a causa de ésto, aparecen algunos programas con fallos en el repositorio del entorno de producción, fallos que en el repositorio de pruebas/desarrollo aparecen corregidos ... o a la inversa; la causa del fallo como siempre, entre la computadora y la silla: los programadores olvidadizos suben sus cambios a un repositorio o al otro y los compañeros ni se enteran o a la inversa: olvidan actualizar su copia local con la de alguno (o ambos repositorios). Se ha tratado por todos los medios posibles que ésta falla de sincronización ocurra, pero en vista que los mecanismos propuestos tiene un factor común (dependencia de la acción/omisión por parte del programador), mi jefe me ha solicitado que se elimine la intervención humana y que las tareas de sincronización de copias locales vs repositorios se ejecuten de manera automática. La infraestructura del escenario consta de servidores GNU/Linux (SVN) y estaciones de trabajo M$-windos. Como mi experiencia con repositorios y automatización de las tareas correspondientes se dirige a /dev/null, acudo a sus conocimientos y experiencia en busca de una solución pronta, efectiva y acorde a los requerimientos de mi jefe. Quedo atento a sus comentarios, sugerencias, indicaciones. Cordialmente, Cuervo Linuxero -- No recibo/envío información elaborados en/para M$-Word, M$-Excel, M$-PowerPoint, M$-Outlook o formatos privativos similares. Le invito a leer mis razones: http://www.gnu.org/philosophy/no-word-attachments.es.html -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-ID:
Hola a tod@s:
Lamento haberme vuelto tan disperso con ésto (llevo 4 hilos con diferentes títulos y buscando una solución a lo mismo), pero es que según concluyo, no se me ha dado la información clara, precisa y concisa.
A ver.
Reproduzco el escenario y la intención final:
Existe un par de redes: una para entorno de desarrollo/pruebas y otra para producción.
Hay un grupo de programadores que tienen acceso a las dos redes ... y no se pueden restringir del acceso a la red de producción.
Ah.
Los males surgen cuando los programadores descargan la copia del repositorio (de pruebas o de producción, no tengo claridad en ésto) a su computadora para trabajar y luego (algunos de ellos) olvidan actualizar el repositorio con su trabajo recién hecho.
Ahhh... pobrecitos. :-p
Al final (ha ocurrido varias veces), a causa de ésto, aparecen algunos programas con fallos en el repositorio del entorno de producción, fallos que en el repositorio de pruebas/desarrollo aparecen corregidos ... o a la inversa; la causa del fallo como siempre, entre la computadora y la silla: los programadores olvidadizos suben sus cambios a un repositorio o al otro y los compañeros ni se enteran o a la inversa: olvidan actualizar su copia local con la de alguno (o ambos repositorios).
¡Uiccch! ¡Ooops! ¡El gato, el gato! ¡El gato es el culpable! Andaba por la sala ayer pisando los teclados.
Se ha tratado por todos los medios posibles que ésta falla de sincronización ocurra, pero en vista que los mecanismos propuestos tiene un factor común (dependencia de la acción/omisión por parte del programador), mi jefe me ha solicitado que se elimine la intervención humana y que las tareas de sincronización de copias locales vs repositorios se ejecuten de manera automática.
(me estoy aguantando la risa)
La infraestructura del escenario consta de servidores GNU/Linux (SVN) y estaciones de trabajo M$-windos.
Como mi experiencia con repositorios y automatización de las tareas correspondientes se dirige a /dev/null, acudo a sus conocimientos y experiencia en busca de una solución pronta, efectiva y acorde a los requerimientos de mi jefe.
Quedo atento a sus comentarios, sugerencias, indicaciones.
¡Que los despidan a todos! X'-) ¡JUASSSS! X'-) Lo siento, no te puedo dar otra solución... me voy a reir a Tumubuctú o un sitio donde no se oigan mis carcajadas... ¡Sorry! X'-) - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjqJywACgkQtTMYHG2NR9X+GgCglG4ZdK7JDWw6zp/mSS4LNgVr wcUAn0pWB7KcqO7Y1aI7/bCJWAdhpMTB =kM9s -----END PGP SIGNATURE-----
Saludos, On Monday 06 October 2008 08:39:46 RŌNIN wrote:
Hola a tod@s:
Lamento haberme vuelto tan disperso con ésto (llevo 4 hilos con diferentes títulos y buscando una solución a lo mismo), pero es que según concluyo, no se me ha dado la información clara, precisa y concisa.
Reproduzco el escenario y la intención final:
Existe un par de redes: una para entorno de desarrollo/pruebas y otra para producción.
Hay un grupo de programadores que tienen acceso a las dos redes ... y no se pueden restringir del acceso a la red de producción.
Y estas personas ¿cómo están organizadas? ¿cómo es el acceso a estos repositorios, la misma clave?
Los males surgen cuando los programadores descargan la copia del repositorio (de pruebas o de producción, no tengo claridad en ésto) a su computadora para trabajar y luego (algunos de ellos) olvidan actualizar el repositorio con su trabajo recién hecho.
?? La idea de que existan dos repositorios es que tienen finalidades diferentes. La de pruebas es para almacenar software beta y el de producción como la fuente de los programas en versión final. Luego hay un administrador de proyecto que asigna responsabilidades y presenta los resultados, supongo que debería ser la persona encargada de comunicar y subir la nueva versión final al repositorio de producción. ¿Tienen un sistema de comunicación interna? Tal vez pueda servir este software para manejo de equipos, erm groupware: http://es.wikipedia.org/wiki/Software_colaborativo Leer también la versión en ingles.
Al final (ha ocurrido varias veces), a causa de ésto, aparecen algunos programas con fallos en el repositorio del entorno de producción, fallos que en el repositorio de pruebas/desarrollo aparecen corregidos ... o a la inversa; la causa del fallo como siempre, entre la computadora y la silla: los programadores olvidadizos suben sus cambios a un repositorio o al otro y los compañeros ni se enteran o a la inversa: olvidan actualizar su copia local con la de alguno (o ambos repositorios).
yo diría que falta organización. A menos que sea que cada programador tiene a su cargo un programa y pareciera que le reporta a nadie sobre los cambios o culminación efectiva del proyecto. =/ De tal manera que todos hacen los que les venga en gana.
Se ha tratado por todos los medios posibles que ésta falla de sincronización ocurra, pero en vista que los mecanismos propuestos tiene un factor común (dependencia de la acción/omisión por parte del programador), mi jefe me ha solicitado que se elimine la intervención humana y que las tareas de sincronización de copias locales vs repositorios se ejecuten de manera automática.
Te podrían representar gráficamente como es el flujo de producción? es decir como inicia, como termina, responsables. O sea documentación, si no la tienen, pues que la hagan y abran los ojos. =P
La infraestructura del escenario consta de servidores GNU/Linux (SVN) y estaciones de trabajo M$-windos.
Como mi experiencia con repositorios y automatización de las tareas correspondientes se dirige a /dev/null, acudo a sus conocimientos y experiencia en busca de una solución pronta, efectiva y acorde a los requerimientos de mi jefe.
Quedo atento a sus comentarios, sugerencias, indicaciones.
Cordialmente,
Cuervo Linuxero --
A simple vista parece un problema de organización, y personalmente no me extraña que te hayan pedido eso. Es más sencillo hacer un "hechizo" (algo que parche el problema) que organizar a la gente para tener una solución eficiente. Bueno ese es mi punto de vista, según lo que compartes con la lista. -- Carlos A. -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Lunes, 6 de Octubre de 2008, RŌNIN escribió:
Se ha tratado por todos los medios posibles que ésta falla de sincronización ocurra, pero en vista que los mecanismos propuestos tiene un factor común (dependencia de la acción/omisión por parte del programador), mi jefe me ha solicitado que se elimine la intervención humana y que las tareas de sincronización de copias locales vs repositorios se ejecuten de manera automática.
La infraestructura del escenario consta de servidores GNU/Linux (SVN) y estaciones de trabajo M$-windos.
Como mi experiencia con repositorios y automatización de las tareas correspondientes se dirige a /dev/null, acudo a sus conocimientos y experiencia en busca de una solución pronta, efectiva y acorde a los requerimientos de mi jefe.
Quedo atento a sus comentarios, sugerencias, indicaciones.
* Esto esta solucionado desde le primer dia de la programacion informatica, si tienes SVN u otro, el problema no son las sincronizaciones, olvidos y demas, el problema es de organizacion, basicamente los desarrolladores han de tener acceso al entorno de desarrollo, en este entorno el jefe de proyectos o el comite o quien vigile el asunto, es quien decide cuando se pasa de fase (alfa, beta, etc) una vez que esto se ha definido como estable y preparado para produccion, despues de los testeos SUYOS en entornos de pruebas, es cuando comunica al Administrador de Sistemas que el producto esta estable, y el Sysadmin (haciendo SUS pruebas o no, depende de si le gusta el riesgo o no) pone el asunto en produccion y debug mode. * Por tanto 1º Los desarrolladores NO acceden a produccion, sus pruebas son en entorno de desarrollo, 2º El Jefe de proyectos/comite NO accede a produccion, sus pruebas son en entorno de desarrollo 3º El Administrador/es de Sistemas son los unicos que acceden a Produccion. 4º Al desarrollador para obligarle a hacer una accion cuando ejecuta un programa o una conexion, depende del entorno de trabajo, si la herramienta es propietaria has de comunicarte con el proveedor para que al lanzar el programa o efectuar la conexion con el repositorio se ejecute un emerge o las tareas que creas que se deban de hacer (asunto de configuracion del cliente). 5º Si las herramientas fueran de codigo abierto (aunque el SO no lo sea) probablemente este comportamiento podrias automatizarlo, al final el log de svn te dira quien cumple y quien no, me parece una barbaridad que un programador no sea capaz de cumplir o hacerle cumplir 2 ordenes, sincronizar cuando empiezas, sincronizar cuando terminas. 6º No todos los desarrolladores (o ninguno) tienen que tener acceso de escritura a los arboles estabilizados o en fase beta.
participants (4)
-
Carlos E. R.
-
jose maria
-
RŌNIN
-
Shinji Ikari