Estoy trabajando en una empresa de SaaS que lanza nuevas funciones y correcciones de errores a nuestros clientes cada seis semanas. Cuando escribimos cambios de código pasan por diferentes pasos (como una máquina de estados) antes de llegar a los servidores de producción. Los pasos son diferentes dependiendo de si el cambio se realiza en el ciclo de desarrollo normal o como una solución de emergencia. Actualmente estamos usando Harvest para administrar los pasos y rastrear qué código (funciones y correcciones de errores a través de paquetes) se está lanzando a los clientes y, en ese sentido, está funcionando bien.¿Cómo las empresas SaaS verifican y rastrean el código que lanzan a los clientes?
Desafortunadamente, Harvest es caro y difícil de usar desde el punto de vista de un programador. La ramificación y la fusión es una pesadilla. Así que estamos buscando cambiar a Mercurial. Mercurial parece sobresalir en esas áreas. Sin embargo, Mercurial no parece estar hecho para rastrear cambios o administrar el proceso mencionado anteriormente, solo lo hace SCM.
Q: ¿Qué opciones tenemos cuando se trata del proceso de lanzamiento, seguramente hay otras compañías de SaaS (por ejemplo, Google, Flickr, Facebook, LinkedIn) que quieren control de calidad antes de lanzar el código a los servidores de producción?
Q: ¿Es una mala idea intentar y construir el proceso en Mercurial o hay otras herramientas que debemos usar junto con Mercurial?
[Editar] Para aclarar, esta es nuestra (sugerido) branch structure.
Aquí está el flujo del proceso que tenemos actualmente en la cosecha:
Hotfix <--> Test Level 1 <--> Test Level 2 <--> Master (Production)
Feature <--> Test <--> Release Test <--> Master (Production)
No estoy buscando un gestor de fallos, sino más bien una herramienta de implementación que nos ayuda a llevar un registro y desplegar código que ha sido verificado por nuestro grupo de expertos (código en la rama de publicación). Si se está trabajando en más de un hotfix al mismo tiempo, necesitamos poder probarlos juntos y si uno rompe el código, tenemos que ser capaces de "degradar" los cambios en el código de un paso atrás en el flujo del proceso. Hoy es suficiente para que los dos desarrolladores "promocionen" sus cambios en el Nivel de prueba 1 y el sistema se puede probar con ambos cambios en conjunto. Si los cambios de un desarrollador solo rompen algo cuando está junto con el código del otro desarrollador, puede volver a degradarse desde el Nivel de prueba 1.
Al "realizar un seguimiento de los cambios", ¿quiere decir "Quiero saber qué versiones cambian X forma parte de" o "para el lanzamiento X, qué cambios forman parte de ello"? –
Este último. También es valioso saber qué cambios están en qué estado en el proceso de lanzamiento. – MdaG
¿No es eso lo que normalmente usa un rastreador de errores para hacer? Lo siento si soy ignorante, no tengo experiencia con Harvest. –