El Mon, 9 Nov 2015 11:07:13 -0300 David Helmut Reese Molinas <drees...@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 <an...@angel-alvarez.com.ar>