práctica de control de versiones

Question

En mi trabajo actual, la práctica del supervisor es verificar el código de producción listo. Más recientemente, el proyecto en el que participé involucró el trabajo de 3 desarrolladores diferentes con cierta superposición de archivos. Esto significó la integración manual de cambios a pesar de que algunos cambios tomaron un día y luego se realizó. Quería ver si esto era una práctica común y obtener sugerencias sobre cómo cambiar esta práctica con el conocimiento de que muchas veces mi opinión significa poco en el gran esquema de las cosas.

Answer 1

Puede usar varias formas de manejar esta situación, dependiendo de su sistema de control de fuente.

Sucursales privadas: le permite registrar y trabajar en el código mientras viaja, fusionándose en los momentos apropiados.

Shelvesets/conjuntos de cambios: pacakaged. Le permiten almacenar conjuntos de cambios y enviarlos para su revisión en todo - la garantía de que están listos para la producción antes de la llegada

En cuanto a si se trata de una forma adecuada para trabajar, no lo hacemos permitir el check-in a las sucursales principales sin revisión previa. Para aprobar la revisión, su código debe pasar varias herramientas automatizadas, y luego debe ser aceptable para su revisor. Para algunas definiciones de "producción lista", esto es todo. Por lo tanto, hacemos algo como lo que haces. Sin embargo, utilizamos las sucursales privadas para garantizar que los check-in aún puedan realizarse mientras esto está en progreso, y que otros check-ins no tienen que interferir.

Si la producción preparada significa probada en un entorno de integración, entonces parece que puede ser necesario organizar ramas o algo similar.

Answer 2

El código que se comprueba debe probarse en una unidad, pero, para mí, "listo para producción" implica que ha pasado por la integración y las pruebas del sistema. No puede hacer eso hasta que el código se congele, por lo que no veo cómo puede hacerlo antes de cada registro.

Answer 3

Yo personalmente no lo aprobaría porque a veces esa es la mejor forma de detectar el código del problema con menos desarrolladores experimentados (al verlo mientras están trabajando en ello) y cuando "se registra temprano y con frecuencia" puede retroceder a los cambios anteriores que realizó (mientras estaba desarrollando) si decide que algunos cambios que hizo anteriormente fueron en realidad mejores idea.

Answer 4

¿No sería una buena idea tener una rama de prueba del repositorio que pueda tener el código no preparado para la producción registrado una vez que los cambios se hayan realizado y probado?

el tronco principal nunca debe tener el código marcado que rompe la construcción y no pasa las pruebas unitarias, pero las sucursales no tienen que tener todas esas restricciones en su lugar.

Answer 5

Creo que puede ser el control de versiones que usamos, VSS en combinación con la falta de tiempo para aprender la ramificación. Me gusta mucho la idea de los check in nocturnos para ayudar con el desarrollo y evitar 'Going Dark'. Puedo ver que es resistente a los troncos pero quizás construye un SS de desarrollo y cuando el código está listo para producción muévelo a la producción SS.

Answer 6

Según las prácticas que he visto, el término calidad de producción se usa como 'espantador' para asegurar que la gente tenga miedo de romper la copa, no es malo para ser sincero porque la parte superior del árbol siempre debería funcionar si es posible.

Yo diría que la mejor práctica es que solo debe fusionar componentes funcionales distintos (es decir, separados) en la parte superior del árbol. Si tiene una superposición significativa de deltas a los mismos archivos fuente, creo que esto "podría" indicar que en algún punto de la línea la gestión del proyecto se ha roto, y que esos desarrolladores deberían haber fusionado sus cambios para separar la rama de integración antes de entrar al fuentes de la línea principal.Un desarrollador individual que dice que la unidad ha probado sus cosas es irrelevante, ¡porque lo que probaron ha cambiado!

Tratando de resolver problemas de integración en la línea de código de su línea principal, inevitablemente se estancarán otras presentaciones no relacionadas.

Answer 7

Suponiendo que se está trabajando en un sistema de control de versiones centralizado (como Subversion), y suponiendo que usted tiene un concepto de "tronco" (donde vive el último código que funciona bien):

Si trabaje en nuevas características en "ramas de características"/"ramas experimentales", entonces está bien para confirmar el código que está lejos de haber terminado. (Cuando se completa la función, se compromete el resultado de buen comportamiento en el "tronco").

Pero no ganará un concurso de popularidad si se comete un código que no se compila/obviamente no funciona en el "tronco" o una "rama de liberación".

Los programadores pragmáticos tienen un libro llamado Pragmatic Version Control using Subversion que incluye una sección con consejos sobre las sucursales.

Answer 8

registro de entrada temprano y el check in a menudo por dos razones principales -

1 - puede ser que haga más fácil la integración de código

2 - en caso de que su equipo explota sus semanas de trabajo no se ha ido

Answer 9

@bpapa

Las copias de seguridad nocturnas de las carpetas de trabajo a los servidores evitarán perder más de un día de trabajo.

@tonyo

Vamos a ver los documentos de requerimientos se completaron el día después de haber terminado la codificación. ¿Eso te dice acerca de nuestra gestión de proyectos?

Somos una pequeña tienda así que si bien usted pensaría que el cambio es fácil, hay algunos aquí que son inflexibles a las viejas costumbres.

Answer 10

Un enfoque que me gusta especialmente es tener diferentes versiones del ciclo de vida en el almacén. Es decir, por ejemplo, tienen una versión de desarrollo del código que es donde los desarrolladores verifican el código en el que se está trabajando; entonces podría tener una versión beta, donde podría agregar soluciones beta a su código; y luego una versión de producción.

En este enfoque hay una sobrecarga obvia, como el hecho de que tendrá un espacio de trabajo más grande en su máquina local, el hecho de que necesitará tener un proceso de migración para mover el código de una etapa al siguiente (lo que significa un congelamiento de código al realizar la prueba de integración que acompaña a la migración), y que dependiendo de la complejidad del proyecto (s) podría necesitar herramientas que cambien la configuración, variables de entorno, entradas de registro, etc.
Todo esto es difícil de configurar, pero solo lo hace una vez, y una vez que lo tiene todo en su lugar, hace que trabajar en diferentes etapas del código sea muy sencillo.

Answer 11

Comience por cambiar de VSS a algo más confiable & rico en funciones.Ver How to convince a company to switch their Source Control

A continuación, aplicar conocido buenas prácticas:

• Check in often
• Recoger los cambios de otros a menudo, para simplificar la fusión
• uso rápido unit tests para asegurarse de que cada cambio se encuentra con una barra mínima
• Requerir que el código registrado siempre se genere y siempre pase las pruebas.

Ahora no estará "listo para la producción" en este punto: aún necesitará un par de semanas para probar & solución antes de poder implementar. Descansar ese tiempo es increíble para usted, y asombroso para su cliente, así que invierta en:

• Pruebas de aceptación automatizadas de alta calidad.