Echa un vistazo para una continuous integration

¿Qué hacen normalmente cuando revisan el código del software de control de versiones para realizar su continuous integration o compilation nocturna? ¿1) extraes el último código, o 2) seleccionas alguna label (es decir, FUNCIONAL) que representa el código más reciente del desarrollador para probar?

Supongo que la respuesta a esto depende de cómo la gente normalmente usa sus repositorys de administración de configuration. ¿Pretendes solo almacenar código que está "completo"? Si ese es el caso, si un desarrollador está trabajando en una tarea durante una semana más o less, él / ella no podrá verificar nada hasta que la tarea esté completa. Sin embargo, si el server de continuous integration simplemente tira de una label bien conocida en lugar de extraer el código más reciente, esto permitirá a los desarrolladores verificar el código con mucha frecuencia, ya que están trabajando para almacenar un historial de su trabajo en progreso. Luego, una vez que se sintieran cómodos con los cambios, podrían labelr su nuevo código con la label FUNCTIONAL.

Solo quería saber las mejores prácticas.

Gracias

Entonces, lo que solemos hacer es tener una twig de "compilation" que el server de CI construye. Fusionamos todo lo que queremos que se incluya en la compilation nocturna en la twig de compilation y se desarrollará allí.

En realidad, no nos desarrollamos frente a la twig de compilation, tenemos twigs de desarrollo que se utilizan para mantener los cambios que no están listos para lanzarse a los entornos de testing.

Las principales recomendaciones que pondría para un IC (más como reglas generales):

  1. Tiene que extraer el código de HEAD / MASTER. Haga que su HEAD / MASTER sea lo más nuevo posible y lo más estable posible.
  2. Nadie puede cometer un código dañado en HEAD / MASTER. Si eso sucede, significa que alguien rompió la construcción.
  3. Quien rompa la construcción tiene que comprometerse a solucionarlo lo antes posible.
  4. Haga que su CI ejecute las comstackciones por compromiso. Entonces, tan pronto como alguien confíe el código roto al HEAD, el CI lo obtendrá y romperá la compilation. La mayoría de los serveres de CI que he visto admiten este modus operandi.
  5. También puede hacer que su CI genere comstackciones nocturnas y etiquete el código cuando generan los packages. Esta también es una buena práctica, y se puede ver que sucede en muchos CI de proyectos de código abierto en todo el mundo.

Parte de mi experiencia: Nuestro CI obtiene extraer el código de HEAD / MASTER. Usamos git aquí, por lo que siempre es muy fácil para nuestros desarrolladores trabajar en las sucursales y mantenerlas sincronizadas, pero solo consiguen establecer un código estable para HEAD / MASTER.

La respuesta correcta se basa en cómo organizas tu código.

Si siempre se supone que la línea principal es estable / funciona, entonces simplemente comstack a partir de eso.

Si tienes una twig que es la twig "dorada", entonces …

En nuestra tienda, tenemos tres types de sucursales:

  • Mainline // siempre edificable, siempre "listo para lanzar una vez que se haga QA"
  • Lanzamientos liberados // dorados, lanzados y liberables en cualquier momento
  • Ramas de desarrollo // donde se realiza una cirugía complicada

(Por supuesto, hacer esto bien requiere un buen vcs. Usamos forzosamente, que tiene ramificaciones increíbles).

Hacemos nuestro edificio continuo desde la línea principal y twigs de lanzamiento.

HTH