2010-06-14 57 views
12

Estaba hablando con otro desarrollador (más antiguo que yo) y tratando de convencerlo de que debemos implementar la integración continua a través de Cruise Control. Me dijo que esto no funcionaría porque él confía el código que no compila al repositorio todo el tiempo con el propósito de respaldarlo. Y que las compilaciones automáticas que nos notifiquen fallas serían solo ruido.Commitir código roto en el repositorio con el fin de realizar una copia de seguridad

Cometer basura al repositorio me suena mal. Pero estaba perdida de palabras y no sabía qué decir. ¿Cuál es la alternativa? ¿Cuál es la mejor práctica para hacer una copia de seguridad de su código en otra máquina sin agregar un montón de revisiones inútiles?

Por cierto, nuestro sistema de control de versiones es SVN y probablemente no cambie pronto.

+2

Estaba a punto de decir "use git!", Pero luego vi la última parte de su publicación ... – marcgg

+0

Es por eso que lo agregué;) –

+3

Lo siento ... Su desarrollador senior comprueba el código que no funciona , y considera que esto es algo bueno? Pobre *******. –

Respuesta

25

Desarrollar en las ramas y comprometer listo para probar y con suerte trabajar ramas en la línea principal. Deje que el servidor de integración continua dependa de la línea principal (en svn la mayoría de las veces llamada troncal) para nuevas revisiones para compilar y validar.

3

¿Cómo compila exactamente todos los demás en su equipo si está ingresando código que no compila?

En general, creo que es un paso en falso comprobar el código en la rama principal que no compila; es realmente desconsiderado para cualquier persona que cuente con poder obtener lo último del control y construcción de la fuente.

TFS tiene algunas características interesantes para solucionar este problema (shelve/unshelve); no estoy seguro si SVN lo hace o no. La mayoría de las veces, cuando alguien está trabajando en un gran cambio y necesita poder registrar el código roto, es mejor que se bifurque y hacer que combine los cambios en la línea principal.

0

Si usted está comprobando en el código rota a una rama que se espera que otros desarrolladores a utilizar, y no mantener una línea de comunicación sobre dicha y lo hace por una buena razón ... bueno, su compañero de trabajo ISN Sigue las mejores prácticas.

Una mejor práctica mutuamente aceptable puede ser exigir que las comprobaciones de "copia de seguridad" del tipo "copia de seguridad" sucedan en una rama privada del desarrollador del código y siempre que el código esté en un estado que no romperá la construcción o pruebas unitarias, se fusiona con una rama de tronco que Cruise Control está mirando.

0

A menos que sea el único desarrollador en la rama (que suena como si no fuera el caso), entonces no debería estar cometiendo un código de última hora. Existen docenas de soluciones para el código de "copia de seguridad" en el desarrollo, que incluyen la creación de una rama privada de la línea actual o la escritura de un pequeño script que realiza una copia de seguridad del directorio de trabajo en un servidor de archivos.

0

Use git para las copias de seguridad/historial local, y las herramientas git-svn para verificar solo las versiones que funcionan.

Cuestiones relacionadas