Metodología recomendada para trabajar con bibliotecas compartidas y Mercurial

7

Trabajo en un pequeño equipo de desarrolladores que colaboran en varios proyectos Zend PHP. Estamos utilizando Mercurial con una colección de repositorios en sentido ascendente, así como Jenkins para las pruebas centralizadas y los informes de salud. Queremos implementar una biblioteca compartida de clases comunes, pero estamos luchando para encontrar un flujo de trabajo que funcione bien con nuestro entorno actual.

Actualmente, cada proyecto contiene una estructura como esta:

- application        (project specific code)
- build              (temporary files generated by each build)
- library            (code used by multiple projects)
    - OurLibrary     (our company’s shared codebase)
    - Zend           (external libraries)
- tests              (test code specific to this project)

La carpeta de la biblioteca está excluida de las pruebas, por lo que hemos creado un proyecto específicamente para ejecutar pruebas unitarias en la biblioteca compartida. Esta decisión se tomó principalmente para evitar el despliegue de las clases de prueba por accidente, algo que se puede mitigar en gran medida mediante una modificación del proceso de compilación automatizada, pero también porque consideramos que era preferible mantener la biblioteca liviana.

Estamos incluyendo la biblioteca en cada proyecto como un sub-repo de Mercurial. Esto significa que los cambios introducidos en la biblioteca por un desarrollador que trabaja en ProjectA no se propagarán automáticamente a ProjectB (bueno), pero tampoco se propagarán al proyecto de prueba de la biblioteca (malo), y Jenkins, por lo tanto, no nos avisará automáticamente de un código de ruptura. La biblioteca (muy mala).

Una situación ideal sería que los desarrolladores puedan enviar cambios a la biblioteca desde cualquier proyecto, y que nuestras herramientas automatizadas ejecuten las últimas pruebas de la biblioteca con el último código de la biblioteca. Además, esto no debería generar un conflicto de versión cuando un desarrollador saca una nueva versión de las pruebas de la biblioteca.

¿Existe una metodología establecida para este tipo de flujo de trabajo, o deberíamos estudiar la estructuración de nuestras prácticas de trabajo de manera un poco diferente antes de comprometernos por completo con los sub-repos?

    
pregunta shanethehat 31.07.2012 - 12:18

2 respuestas

2

Si fuera yo, configuraría el proyecto 'OurLibrary' como cualquier otro. es decir, como un solo proyecto que incluye pruebas.

No veo cómo exponer las pruebas de un proyecto a otros proyectos nunca sería problemático: ya que las pruebas son parte de su documentación, ¡realmente diría que sería una buena cosa!

Si realmente no es posible por alguna razón, otra opción a considerar es que los proyectos usen una versión compilada de 'OurLibrary'. Esto tiene algunos inconvenientes propios aunque, por ejemplo, tener que gestionar la versión compilada de la biblioteca; no poder editar el proyecto de código 'OurLibrary' directamente de otros proyectos; etc.

    
respondido por el vaughandroid 31.07.2012 - 18:03
2

El último recurso

Considera que los sub-repos son considerados una característica de último recurso .

Esto significa esencialmente que no debes usar sub-repos a menos que tengas una razón legítima, tienes una razón legítima, así que hazlo.

¿Cuándo entonces?

Tengo algunas reglas básicas para los subrepos, por lo tanto, las uso solo si:

  • Ya tengo el subrepo como un repositorio independiente (es decir, no es una biblioteca que pueda estar incubando) Y
  • (Es el código que tengo O el código en el sub-repositorio está siendo desarrollado activamente) Y
  • La actualización del código no es trivial Y
  • (Existe una situación potencial en la que podría querer editar el código de subrepo y rechazarlo O bifurque el código de subrepo con un nuevo proyecto específico, al mismo tiempo que puedo extraer e integrar los últimos cambios en ese repositorio (mantiene las cosas flexibles en emergencias y plazos)).

Última razón ...

Gestión de la configuración : cuando quiero hacer un seguimiento de qué versiones de qué coexisten con qué versiones de lo que sea y, lo que es más importante, quiero tener el control de estos.

Por ejemplo, diga que desea probar su última rama de desarrollo / experimental de "Nuestra biblioteca" con el código de producción de su proyecto actual. Tener subrepos en esta situación es muy útil.

Sigue haciéndote preguntas

Es posible que te sientas cómodo con la idea de utilizar subrepos. No lo hagas Sigue preguntándote "¿cuándo no debería usar subreposiciones?", Si no tienes una buena razón, simplemente no las uses y todo estará bien.

Relájate

Diga que no usó subpospos y terminó dándose cuenta de que debería haber debido a la razón X: siempre puede corregirlo más tarde, en cualquier caso, no necesita el historial de subrepo para su proyecto actual.

En un caso extremo en el que quería eliminar los archivos donde se suponía que debía estar el subpopo desde el día 0, use < strong> ConvertExtension para extraer el subrepo con un archivo filemap.

No recomendaría esto para su caso (donde su proyecto principal es el padre del subrepo deseado), pero será útil para el caso de uso de administración de configuración en el que tendrá un nuevo repositorio principal para manejar versiones entre componentes y su proyecto principal es uno de ellos (en el mismo nivel del subrepo que desea), por ejemplo:

project (repo)
|-component1
|-component2
|-component3

Se convierte en

project (new-repo)
|-component1 (subrepo)
|-component2 (subrepo)
|-component3 (subrepo)

De lo contrario con:

project (repo)
|-app
|-lib
|--|-libA
|--|-libB

Convirtiéndose en

project (repo)
|-app
|-lib
|--|-libA (subrepo)
|--|-libB

Dejarás un agujero en tu historial donde no exista libA hasta que crees la entrada .hgsub.

    
respondido por el dukeofgaming 01.08.2012 - 02:25

Lea otras preguntas en las etiquetas