¿Tienes alguna política de compromiso?

Question

Mi jefe anunció ayer una nueva política de confirmación para los registros en el repositorio. Estas políticas son válidas para compromisos en cabeza / troncal y sucursales.
Un mensaje de confirmación debe tener los siguientes elementos:

• Motivo (ID de error, ID de proyecto o cambio no funcional)
• Nombre del revisor

Después de la confirmación, también tenemos que crear una entrada de blog de cambio en nuestro CMS.

No soy un gran fanático de estas políticas de compromiso, porque normalmente no necesito un revisor cuando estoy haciendo cosas nuevas o experimentales en una rama no productiva.

¿Tiene alguna política de confirmación que deba seguir?

Creo que es una buena idea cambiar la rama productiva solo debido a un informe de error, pero los compromisos en las ramas de desarrollo deberían ser menos restrictivos.

Answer 1

Comprométete temprano y comprométete a menudo.

En realidad usamos / trunk como desarrollo y etiquetas para ramificar diferentes versiones. Sólo los cambios estructurales intrusivos entran en / ramas.

Utilizamos etiquetas de forma activa para lanzamientos de producción y aceptación, por lo que podemos retroceder en el tiempo fácilmente. Cualquier cosa confirmada en el troncal solo debe tener un mensaje que describa lo que la confirmación cambió o agregó brevemente.

No soy un gran fan de usar el espacio de mensajes para enlazar con ID de error. Todavía requiere una búsqueda de la ID, en cuyo caso también puede buscarlo en el software de seguimiento de errores y cerrarlo allí, lo que para mí es sobre el mismo esfuerzo.

No quiere decir que no me guste ninguna integración svn: - Usamos más bondades de los scripts de nant automatizados para realizar lanzamientos que los bifurcan en / tags - svn props realmente almacenan nuestros números de versión: p. - enganche de scripts para notificaciones de correo electrónico y registro de mensajes (ideal para copiar y pegar notas de la versión).

Answer 2

Tenemos una serie de políticas, que se aplican mediante un complemento interno de Visual Studio. Verificamos que el código se compile y que las pruebas unitarias se hayan ejecutado con éxito. En este momento también verificamos la cobertura del código y emitimos advertencias para el código que no tiene suficientes pruebas. También realizamos varias verificaciones de consistencia y verificamos que una tarea apropiada esté presente en nuestro sistema de administración de cambios para proporcionar trazabilidad a todos los cambios.

La ventaja de la compatibilidad con herramientas es excelente, ya que no corresponde realmente a las personas respetar las políticas, pero obviamente hay un inconveniente y estos controles requieren tiempo para ejecutarse. Sin embargo, con muchos desarrolladores es difícil hacer cumplir los estándares sin el soporte adecuado de las herramientas.

Answer 3

Un revisor parece inútil por las razones que mencionó, porque no todo tiene que ser revisado por otros.

En el pasado, la única política de confirmación que teníamos (donde solía trabajar) era incluir un comentario que indicara qué has cambiado y por qué, pero eso es más común que cualquier otra cosa.

Answer 4

Una política de confirmación común es asociar un ID de error a la confirmación a un troncal como una justificación. A veces, los sistemas de control de versiones y de seguimiento de errores están configurados para hacer cumplir esta política.

Answer 5

Nuestra política de confirmación suena un poco como la tuya, solo que no la aplicamos en las ramas de tareas (donde una rama de tareas es como un recinto de prueba para desarrolladores para la experimentación).

Nuestros comentarios de confirmación deben incluir un ID de control de cambios (nueva función, mejora) o un ID de problema (corrección de errores). También debe incluir una breve explicación sobre por qué que realizó este cambio; el control de versiones rastrea el quién, qué, cuándo y dónde.

Answer 6

Mi mensaje de confirmación incluye una breve descripción de lo que he implementado o cambiado en las clases.

El número de error y las descripciones adicionales que puse en el comentario sobre el nuevo código. Identificaciones dentro de los mensajes de confirmación que colocamos cuando fusionamos cambios en una etiqueta etiquetada.

Cada noche, una compilación automática verifica las diferentes características y productos, así que asegúrate de que el código base sea estable.

Pero al final creo que no puede tener demasiadas descripciones para clases nuevas o modificadas, sino demasiadas políticas que debe realizar antes de un compromiso. El nombre del revisor es algo que no pondría en el mensaje de confirmación.

Piensa que a veces tienes que entender tu código que implementaste hace 2 años. Y luego está contento con los mensajes de confirmación que no son como " Actualizar después de la depuración " ;.

Answer 7

Tenemos sucursales para cada versión principal lanzada del software que aún se admita activamente. El registro en cualquiera de estas sucursales requiere un ID de error, que se aplica mediante scmbug , que no solo verifique que el comentario esté precedido por el ID de error, sino que también buscará este error en la base de datos de errores, asegúrese de que esté asignado al interlocutor, y posiblemente verifique otros criterios (por ejemplo, que el campo " corregir en la rama " es la rama está comprometida a).

Uno de los productos tiene más posibilidades de fallar de manera vergonzosa, y los registros para esto requieren no solo un ID de error, sino también una revisión del código. Sin embargo, los criterios para la revisión del código se manejan en nuestra base de datos de errores: tenemos campos personalizados para esto y el error no se puede aceptar ni cerrar hasta que se haya revisado. Para mí, esto funciona desde un nivel conceptual. Probablemente sea mejor verificar el código que se cree que funciona en el repositorio sin revisar, luego volver a abrir el error y cambiarlo si es necesario en lugar de esperar a que se confirme hasta que esté seguro está listo para su lanzamiento.

Aparte de eso, no hay una política explícita para el troncal (aunque, por supuesto, los principios generales de la verificación a menudo sin romper la compilación, incluidos los buenos mensajes de confirmación descriptivos, la verificación de las unidades de trabajo que aún se aplican).