El Mon, 9 Nov 2015 11:07:13 -0300
David Helmut Reese Molinas <dreese17@gmail.com> escribió:
> Buen Dia
>
> Sé que el tema es bastante OT, pero tomando en cuenta que la mayoria de los
> que están en esta lista tienen experiencia en desarrollo con proyectos
> grandes me parece que podriamos compartir algunas experiencias de manera a
> poder solucionar un dilema que estoy teniendo.
> No es precisamente un problema, sino más bien un tema de organización. Me
> interesa saber cómo lo hacen (o lo harían si aún no tuvieron la
> experiencia) en un panorama como el siguiente.
>
Ni siquiera califica como OT
--
> Estamos trabajando en un proyecto de sistema web basado en servicios.
> Tenemos el proyecto de la capa backend y el de la capa front-end en dos
> proyectos separados, por tanto también repositorios separados, dentro del
> GitLab institucional.
>
> Como nuestro backend aún no es una rama estable, los servicios podrían
> sufrir cambios en cuanto los datos que reciben tanto como los que devuelven.
> Lo mismo sucede con la capa del front-end, con la diferencia de que el
> front-end obviamente depende de los servicios para funcionar.
>
> Actualmente estamos manejando el esquema recomendado por GIT para los
> branches (las explicaciones están resumidas, pero espero que se entiendan):
> - Master: El release de produccion
> - Develop: El release de testing, utilizado para pruebas de integración
> antes del paso a producción
> - Hot-fixes: Para corrección de errores
> - Features: Para las nuevas funcionalidades o actualizaciones sobre
> funcionalidades existentes.
>
> El tema es que cada capa (front-end y back-end), al tratarse cada uno de un
> proyecto "independiente", tiene su propio numero de version y release.
> Por ahora lo que hacemos es separar los pasos a producción (actualmente en
> beta) de ambos proyectos en dos partes:
>
> -- La primera es el lanzamiento del release de cada proyecto conteniendo
> modificaciones que no afecten al otro proyecto:
> --------- Por ejemplo: Corrección de un error en el back-end, cambio de una
> etiqueta en el front-end, etc.
>
> -- La segunda es el lanzamiento de releases conteniendo modificaciones que
> afecten al otro proyecto, o sea que el paso a producción se hace de ambos
> proyectos a la vez:
> --------- Por ejemplo:
> --------- Se elimina un campo en algún servicio en el back-end,
> --------- el front-end necesita consumir ese servicio y al no encontrar un
> campo, la aplicación lanza un error hasta que sea corregido el codigo en el
> front-end
>
> El problema que estamos teniendo es con la segundo tipo de paso a
> producción mencionado; y aquí me explico mejor:
> Cuando se lanza una modificacion a un servicio (proyecto backend) se
> verifica que todo funcione en el proyecto y se pasa a develop.
> Se trabaja entonces con las modificaciones en el front-end para consumir el
> servicio con esta modificación.
>
> ¿Cómo nos organizaríamos o deberíamos organizarnos con los releases de cada
> proyecto como para no lanzar una version que pueda romper algo en el otro
> proyecto?
>
> Me recomendaron crear dos numeraciones de releases en los milestones...
> - un número de versión sería la de cada proyecto individual, o sea,
> backend-1.0.4 o frontend-1.2.3...
> - otra numeración de sería la de el proyecto completo... Proyecto-1.3
>
> O sea que si se crea un milestone (sería para identificar todo lo que
> debería entrar en una versión específica) backend-1.0.5 entendemos que
> todavia no se lanzará a producción, pero si se crea un milestone
> proyecto-1.0.6 corresponde a lo que se lanzará a producción en conjunto con
> el frontend, y espera a que en el otro proyecto alcance el mismo milestone
> proyecto-1.0.6 para lanzar ambos al mismo tiempo...
>
> La idea es saber siempre cuando estoy "habilitado" a lanzar una
> modificación a producción del backend sin que esto afecte negativamente al
> frontend... es bastante trivial hasta cierto punto, pero igualmente siempre
> tenemos problemas, y si bien estoy recibiendo bastantes consejos de otros
> colegas me gustaría conocer la opinión de la comunidad.
>
> Siento mucho si no se entiende correctamente, estoy haciendo un esfuerzo
> por explicarlo bien.
> Igualmente gracias por si se tomaron el tiempo de leerlo y tratar de
> entenderlo, y perdonen si les parece una pérdida de tiempo.
>
> Gracias de antemano para todos
>
> --
> ----------------------------------------
> David H. Reese M.
> Investigación y Desarrollo
> Dirección Nacional de Contrataciones Públicas
> Asunción - Paraguay
> Teléfono: 595 971 351390
> ----------------------------------------
Angel Claudio Alvarez <angel@angel-alvarez.com.ar>