¿Tiene alguna política de compromiso?

Mi jefe anunció ayer una nueva política de compromiso para checkins en el repository. Estas políticas son válidas para commits en head / trunk y branches.
Un post de confirmación debe tener los siguientes elementos:

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

Después del compromiso también tenemos que crear una input de blog de cambio en nuestro CMS.

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

¿Tiene alguna política de compromiso que deba seguir?

Creo que es una buena idea cambiar la twig productiva solo debido a un Informe de errores, pero las ramificaciones de desarrollo deben ser less restrictivas.

Comprométase temprano y comprométase a menudo.

En realidad usamos / trunk como desarrollo y tags para ramificar diferentes lanzamientos. Solo cambios intrusivos estructurales entran en / branches.

Usamos activamente tags para lanzamientos de producción y aceptación, por lo que podemos retroceder en el time fácilmente. Todo lo que se haya comprometido en el enlace troncal solo debe tener un post que describa lo que ha cambiado o agregado brevemente.

No soy un gran admirador de usar el espacio de posts para vincularme con las ID de Bug, aún así necesito search el ID, en cuyo caso también puedes searchlo en el software de seguimiento de errores y cerrarlo allí, que para mí es sobre el mismo esfuerzo.

No quiero decir que no me gusta ninguna integración de svn: – Usamos más bondad de scripts automatizados nant para hacer lanzamientos que los ramifican en / tags – svn props realmente almacena nuestros numbers de versión: p. – Scripts de enganche para notifications por correo electrónico y logging de posts (ideal para copyr y pegar notas de la versión).

Tenemos una serie de políticas, que se aplican a través de un plug-in interno para Visual Studio. Verificamos que las comstackciones de códigos y las testings de unidades se hayan ejecutado con éxito. Por el momento, también verificamos la cobertura del código y emitimos advertencias para el código que no tiene suficientes testings. También realizamos varias comprobaciones de consistencia y verificamos que una tarea apropiada esté presente en nuestro sistema de gestión de cambios para poder proporcionar trazabilidad para todos los cambios.

La ventaja del soporte de herramientas es excelente, ya que no depende de las personas respetar las políticas, pero obviamente hay un inconveniente y estas comprobaciones tardan en ejecutarse. Sin embargo, con muchos desarrolladores es difícil hacer cumplir las normas sin el soporte adecuado de la herramienta.

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

En el pasado, la única política de compromiso que teníamos (donde solía trabajar) era include un comentario que indicaba qué había cambiado y por qué, pero eso tiene más sentido común que cualquier otra cosa.

Una política de compromiso común es asociar un ID de error al compromiso con el tronco como una justificación. A veces, el control de versiones y los sistemas de seguimiento de errores están configurados para hacer cumplir esta política.

Nuestra política de compromiso se parece un poco a la tuya, pero no la aplicamos en las twigs de tareas (donde una twig de tareas es como un banco de testings del desarrollador para experimentar).

Nuestros comentarios de compromiso deben include un ID de control de cambios (nueva function, mejora) o un ID de problema (corrección de errores). También debe include una breve explicación de por qué hizo este cambio; control de versiones rastrea quién, qué, cuándo y dónde.

Mi post de compromiso incluye una breve descripción de lo que he implementado o modificado en las classs.

El número de error y las descripciones adicionales que puse en la descripción sobre el nuevo código. ID dentro de los posts de compromiso que ponemos cuando fusionamos los cambios en una twig labelda.

Todas las noches, una compilation automática comtesting las diferentes características y productos para asegurarse de que la base del código sea estable.

Pero al final, creo que no se pueden tener demasiadas descripciones para las classs nuevas o modificadas, pero hay demasiadas políticas que hay que hacer antes de una confirmación. El nombre del revisor es algo que no pondré en el post de confirmación.

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

Tenemos sucursales para cada versión principal lanzada del software que todavía se admite activamente. Verificar en cualquiera de estas twigs requiere una identificación de error – esto es implementado por scmbug , que no solo verificará que el comentario tenga el prefijo ID del error, sino que también searchá este error en la database de errores, asegúrese de que esté asignado al committer, y potencialmente puede verificar otros criterios (por ejemplo, que el campo "arreglar en la sucursal" es la twig a la que se está comprometiendo).

Uno de los productos tiene más posibilidades de fallar de manera embarazosa, y los controles a esto requieren no solo una identificación de error sino también una revisión de código. Sin embargo, los criterios para la revisión del código se manejan en nuestra database de errores: tenemos campos personalizados para esto y el error no se puede aceptar y 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 repository sin revisión, luego reabrir el error y cambiarlo si es necesario en lugar de esperar hasta que estés seguro de que está listo. para el lanzamiento.

Aparte de eso, no hay una política explícita para el enlace troncal (aunque, por supuesto, los principios generales de check-in a menudo sin romper la compilation, incluidos los buenos posts descriptivos de compromiso, se siguen aplicando las unidades de trabajo atómicamente).