¿Qué políticas de check-in deben tenerse en cuenta para el control de versiones?

Question

Tengo la tarea de ayudar a configurar las plantillas de proceso y las políticas de check-in para la instalación de TFS 2008 de mi empresa.

Aparte de tres políticas de check-in (una acción de check-in debe tener comentarios en contra, un archivo de código debe ser revisado por pares, debe haber un elemento de trabajo asociado con un check-in), se me ha preguntado considerar e implementar cualquier otro.

¿Cuáles son algunas de las políticas más importantes o útiles para aplicar para el control de versiones?

Answer 1

Cuanto menor sea el mejor.

Por lo general, en una organización que desea aliviar la fricción del check-in para asegurarse de que está alentando a los desarrolladores a hacer frecuentes pequeños y discretos check-ins en lugar de echar un vistazo a un montón de cosas a la vez. Por otra parte, debe asegurarse de tener una base de código funcional para todos los que la necesitan y de capturar los datos que necesita para mejorar el proceso de entrega del software.

En lo personal, una política para hacer cumplir los comentarios del conjunto de cambios y una política de asociación de elementos de trabajo están bien - ya que la captura de meta-datos que es muy fácil de recordar en el momento pero difícil de encontrar después. También alienta a los desarrolladores a adquirir el hábito de tener un elemento de trabajo para rastrear todos los trabajos, incluso el desarrollo experimental o los picos.

El proceso de revisión podría llevarse a cabo mejor usando ramificación o de otro proceso en lugar de forzar una revisión por pares en cada registro de entrada - sin embargo, que depende de su proceso.Recuerde también que puede tener notas de check-in obligatorias en TFS para capturar metadatos como el revisor de código. Una nota de check-in es ligeramente diferente a una política de check-in y a menudo se confunde.

Si desea leer más discusión sobre las políticas de check-in, eche un vistazo a blog post I did on the balancing act a while ago. También para escuchar un poco más de discusión acerca de las políticas de check-in, grabé un podcast recientemente con un Team Team MVP que habla sobre su uso de TFS y podría ser interesante (Radio TFS, Using TFS with Ed Blankenship). Finalmente también hicimos un Radio TFS episode all about check-in policies en 2008 que podría ser de interés.

Answer 2

Algunas reglas que seguimos en nuestra empresa:

• confirmar todos los cambios relacionados con la misma tarea a la vez (que ayudará a revisar los cambios y restauraciones futuras o se funde si es necesario).
• comentarios basados ​​en plantillas (por ej .: prefijar todos los comentarios con un código que represente lo que se hizo, + para agregar, - para quitar, * para actualizaciones,! Para modificaciones importantes, etc.).
• Obviamente, siempre el código de check-in se compila y finaliza el trabajo en la línea principal.
• check-in el trabajo diario sin terminar a las ramas.

Answer 3

¡No rompa la construcción! Por supuesto, encontrar una forma automática de verificar eso y rechazar el check-in es el desafío.

Answer 4

Francamente, cuanto menos políticas, mejor. Cuantas más políticas tenga, mayor será el incentivo para NO usar el control de versiones. Lo que sucede entonces es:

• El código se desarrolla en sistemas de control de fuente paralelos e incontrolados, y solo la revisión final va al oficial.
• Las personas tardan en comprometerse tanto como sea posible, disminuyendo la visibilidad de lo que están haciendo a otros desarrolladores.
• La gente realmente evitará cometer algo si puede salirse con la suya, y algunos encontrarán la manera de salirse con la suya.

De hecho, creo que sus tres políticas de check-in ya son demasiado. Por ejemplo:

• Tener código revisado por pares antes del check-in hace que sea mucho más difícil tener el trabajo en progreso almacenado allí. En cambio, si el sistema de control de origen lo permite (y muchos lo hacen), controle si la fuente es revisada por pares o no. Con algunos sistemas puede crear un ciclo de vida para una revisión, con otros puede crear sucursales, y otros pueden usar etiquetas.
• Tener un elemento de trabajo asociado con un check-in hace que sea imposible para los desarrolladores realizar una programación exploratoria o tener iniciativa sobre posibles mejoras. Ahoga a los desarrolladores. En su lugar, asegúrese de que cualquier revisión que vaya a pruebas de integración o pruebas de aceptación del usuario, sin mencionar la producción en sí misma, esté asociada con un elemento de trabajo.

Esto puede sonar anti-Enterprise, pero es solo algunas de las cosas que hemos aprendido en unas pocas décadas de desarrollo de software. La mayoría de las organizaciones empresariales no han sido informadas sobre esto, pero, eventualmente, lo harán. Entonces, puedes ir por el camino opuesto, pero no digas que nadie te lo dijo.

Recomiendo el Agile Manifest, y, en particular, Lean Software Development para principios generales.

O, teniendo la filosofía de diseño de desbordamiento de pila en cuenta, hacen que el sistema de recompensa el comportamiento que desea.

Answer 5

tratar de mantener el número de desarrolladores que trabajan en la misma rama pequeña. De esta forma, la sucursal se mantiene estable con respecto a la compilación, las pruebas unitarias y las regresiones. Es una pesadilla si un desarrollador realiza un control en el que compila, pero su código rompe un área clave de la aplicación (como el inicio de sesión).

Si realmente tiene que tener más de 10 desarrolladores de comprobación de código en la misma rama, hemos iniciado una política de correo electrónico donde el desarrollador comprobar en todo el mundo advierte que están en la comprobación, para que nadie intente actualizar su copia de la rama en medio de un cheque. a veces, hemos tenido que tienen la inversa, cuando dejamos a un lado una vez en la fecha de prohibir compra de registro, por lo que las actualizaciones son seguros.

Answer 6

Los que usamos en la que trabajo en TFS son:

• análisis de código
  • Esto asegura que todo el código fue compilado en el equipo de desarrolladores antes de que se comprobó en
• Asociación de artículos de trabajo
  • Si ha hecho un cambio, debería haber habido una ¡tarea asignada!
• Última generación correcta
  • Utilizando el TFS de creación de servidores para comprobar que el código actual en el control de código fuente compilado en una máquina independiente
• Entradas Comentarios (parte de los Powertools TFS - http://msdn.microsoft.com/en-us/teamsystem/bb980963.aspx)
  • es bueno ser capaz de ver un resumen del cheque sin tener que ir al elemento (s) de trabajo