Soy un contratista que recientemente comenzó con una empresa.
El equipo es de 3 desarrolladores que consta de 2 desarrolladores de nivel junior a medio, con otro en el mismo nivel que comenzará pronto, y yo (6 años xp). Tanto para los desarrolladores existentes es su primer trabajo fuera de la universidad / colegio, y nunca antes han tenido un desarrollador senior que supervise su trabajo.
No existe una política explícita de control de versiones. Los desarrolladores realizan todo el desarrollo en el tronco y luego lo implementan en producción directamente desde sus máquinas de desarrollo. El equipo existente no está familiarizado con la ramificación.
Estoy cambiando todo esto e introduciendo CI, servidores de prueba / preparación / producción de TDD, etc., junto con una política de control de versiones para complementar esto.
El sistema de control de fuente es TFS, que nunca he usado antes. Está configurado como un repositorio gigante.
He escrito algunos consejos para ellos, pero ¿hay algo más que deba agregar / modificar, teniendo en cuenta la experiencia del equipo?
Política de control de versiones
El desarrollo se realiza en el tronco.
Si se estima que un cambio demorará más de una semana, entonces debe hacerse en una rama, con fusiones regulares desde el tronco hacia la rama para evitar que los dos se desincronicen.
Liberar ramas creadas para el código de producción. Esa rama solo debe contener código estable. Podemos tener una rama de lanzamiento que se actualiza desde el tronco una vez por sprint, o podemos hacer una rama de lanzamiento separada para cada semana.
Si es necesario realizar una corrección de errores urgente que afecte al código de producción, se realiza en la rama de lanzamiento y se fusiona nuevamente en el tronco.
Si adoptamos la estrategia de una rama de lanzamiento, el tronco se fusiona con la rama de lanzamiento una vez por sprint hacia el final del sprint.
Si adoptamos la rama separada por estrategia de lanzamiento, el tronco NUNCA se fusiona con la rama de lanzamiento
En algunos escenarios, puede ser necesario corregir el error dos veces en diferentes ramas, si las ramas han divergido demasiado. Si estamos haciendo carreras cortas, esto no debería suceder con demasiada frecuencia.
Planeo tener tres servidores. Entorno de prueba que siempre ejecuta el último código en el repositorio. Un entorno de ensayo que ejecuta el último candidato de lanzamiento para ensayo / prueba del código de candidato de lanzamiento y propósitos de UAT, y el entorno de producción.
La razón por la que planeo hacer esto es que hasta ahora el cliente solo ha hecho software interno. El proyecto más nuevo es para un cliente de medios de alto perfil, y creo que el equipo necesita adoptar un modelo de desarrollo más profesional que el que hacen en este momento.
Por ejemplo, en este momento, un usuario puede telefonear al equipo con un informe de error. Los desarrolladores localizan y corrigen el error, hacen una prueba rápida de globo ocular en sus propias máquinas y luego lo implementan directamente en producción. Sin pruebas automatizadas ni nada.
En retrospectiva, creo que la rama de características está demasiado lejos y la eliminaré.
Así que esencialmente se reduce a a) no ramificación en absoluto) b) una rama de liberación y el tronco, y c) una rama de liberación por liberación y el tronco.
Me inclinaba hacia lo último. Mi pensamiento inicial sería que tendría un candidato de lanzamiento y un lanzamiento para estar en vivo en servidores separados (UAT / Producción) al mismo tiempo, pero efectivamente el enlace troncal es el candidato de lanzamiento en cualquier momento, por lo que una rama por la liberación se inclina hacia la locura. Lo único que pensaría sería que si no quisiéramos que nuestras partes interesadas vieran el código de desarrollo, entonces podríamos necesitar una rama candidata de lanzamiento por separado, pero YAGNI y todo eso .....