Estamos hablando de la la Promotional Model - papel de Perforce pone de relieve los problemas con él - se comunican los roles cambiantes de los códigos de líneas móviles y trabajo entre las ramas.
Una expansión en mis puntos de vista de los problemas mencionados:
1) Modificación de la política de código líneas:
Cada línea de código tiene una política, ya sea por escrito y formalizado, o en su totalidad implícita en una cabeza del desarrollador. Se define por ejemplo:
- que se le permite a comprometerse con el código línea
- la cantidad de pruebas que se requiere (por ejemplo, hacer la unidad de pruebas tienen que pasar, pruebas de regresión, prueba del sistema completo)
- ¿Cuántas personas tienen a la revisión de código cambia
- qué tipo de cambios están permitidos
Con el enfoque troncal, las políticas permanecen fijas, por lo que son más fáciles de anotar, lo que las hace más fáciles de comunicar (más importante en un equipo más grande).
p. Ej.Tronco:
- cualquier desarrollador puede cometer
- cualquier cambio
- pruebas unitarias deben pasar
- revisión de código después de cometer
rama Versión:
- único desarrollador de mantenimiento
- única corrección de errores
pruebas de ensayo + regresión
- unidad
- revisión de código por otros 2 desarrollador antes de cometer
rama Etiqueta:
- no compromete después de la creación
desarrollador de privada sucursal:
- Sólo los controles de desarrolladores en
- Cualquier cambio
- Prueba sólo necesitaba antes de la fusión en el tronco
- revisión de código antes de la fusión en el tronco
Si usted tiene el modelo de promoción, entonces usted tiene una póliza mientras se encuentre en el desarrollo principal, debe decirle a todos cuándo cambia la política mientras se prepara para la publicación, luego otra política (para la línea de código) una vez que se libere la línea.
El modelo de promoción es fácil de obtener, se asigna directamente al modo de trabajo sin control de origen. Pero duele una vez que comienzas a obtener equipos grandes.
Si observa el desarrollo del kernel de Linux, puede ver la tensión entre el modelo promocional y el modelo troncal: el árbol de Linus es promocional: pasa por ciclos entre la ventana de fusión y el período de estabilización/rc. Pero Linux-next y -mm han surgido para dar una línea más troncal.
Los SCM/VCS distribuidos son de todos modos algo diferentes, las políticas no tienen que distribuirse a todos los desarrolladores porque cada desarrollador tiene sus propios árboles y realiza cambios cuando lo desea.
Los proyectos de código abierto adolecen del problema de que no pueden obligar a las personas a realizar el trabajo pesado de estabilizar un lanzamiento, después de la bifurcación del tronco. Por lo tanto, el modelo de promoción es más importante como una forma de forzar los esfuerzos de estabilización, en lugar de solo trabajar en las características.
2) Movimiento de trabajo:
Un desarrollador podría estar trabajando en una característica cuando la política para la línea que está trabajando en los cambios en correcciones de errores solamente, que ahora tiene que cambiar su copia de trabajo a un código- diferente línea. Esto puede ser de fácil a extremadamente difícil dependiendo del sistema SCM en uso. Este problema no ocurre si el desarrollador está trabajando en el tronco, ya que su trabajo siempre va a la troncal.Si el desarrollador se encuentra en una rama privada o característica, entonces su trabajo solo afectará a la troncal (y la versión) en absoluto.
Si una característica ya está registrada, pero se retrasa con respecto a la versión en la que se encuentra actualmente, debe averiguar cómo eliminarla. Este problema aún existe con el modelo de troncales, pero podría ser un poco más fácil de resolver: recoger cosas del tronco para el lanzamiento. Aquí es donde las ramas de características ayudan, pero tienen un costo de integración.
+1 para el enlace al excelente artículo! – RichardOD
Muy buen artículo, gracias Douglas. – Sebastian
Genial - Recibo 6 votos positivos, y la pregunta se ha realizado CW: -) ... –