Tiempo de lectura: 20 minutos.
Público objetivo: Desarrolladores y Administradores de proyectos de software
Nivel: Básico.
Fecha publicación: 22 de Diciembre de 2017
Hola nuevamente, en mi segunda entrada de Blog les compartiré algunas de las prácticas que nos han funcionado para administrar mejor, optimizar el tiempo y mejorar la calidad de los proyectos de software en la empresa (xPage, Fist, xShop y algunos desarrollos personalizados), además también les comentare de algunas herramientas que hemos usado y que NO nos han funcionado y de otras que sí nos han funcionado muy bien y que estamos usando actualmente.
Si estas empezando a desarrollar software con un equipo o sientes que muchas de las cosas que programan no son muy ordenadas u optimizadas les aseguro que aprenderán mucho de esta entrada de blog.
El saber como hacer las cosas ha evolucionado de acuerdo a la experiencia que hemos adquirido de los software que hemos construido desde el 2013. Tan grave era el tema que algunos de los desarrollos no estaban siquiera versionados, simplemente se programaba el código en local y se actualizaban los archivos manualmente en el servidor, lo se, algo terrible.
Board de Gitlab
Para manejar issues, tareas, mejoras etc. empezamos a usar trello pero nos dimos cuenta de que muchas de las cosas que escribimos alli, ahi se quedaban, no se seguía haciendo revisiones de esa herramienta, solo unos meses después que volviamos a revisar nos dábamos cuenta de que ni siquiera las tareas que habíamos terminado estaban marcadas como terminadas o las cosas que planeabamos desarrollar no se habían hecho por darle prioridad a otras, cosa que era bastante frustrante.
Luego decidimos empezar a usar taiga junto a slack y gitlab (manejador de versiones, en mi concepto mejor que github en usabilidad y similar o mejor en funcionalidad), en un intento de manejar mejor las tareas y enterar a todo el equipo de lo que se había planeado, de lo que se estaba haciendo y de lo que que se había terminado, cada actualización en gitlab quedaba registrada en taiga y además se enviaba un mensaje a algunos de los grupos de slack, teníamos un grupo de clientes, desarrolladores, community, uno general, en fin era demasiada información, y para algunos de las personas en los grupos no era siquiera información relevante.
Al final paso lo mismo que con trello, simplemente dejamos de usar esta combinación.
Por ese tiempo el equipo de gitlab empezó a mejorar demasiado su sistema, en usabilidad, en nuevas funcionalidades, estéticamente, empezamos a ver que incorporó módulos para administración de proyectos, algo muy similar a trello o taiga, solo que todo en uno, hasta el momento es lo que estamos usando y lo que nos funciona muy bien.
Ejemplos de merge request
Tener estándares de codificación (pep8, es6), estándares para el idioma en que codificamos (Todo en ingles), para el idioma en que redactamos issues y merge requests (En español para mejorar el entendimiento de todo el equipo), estándares para la forma en que se encontró un issue y para como testear un merge request nos han dado mucho orden en lo que hacemos, optimizamos el tiempo y lo que hacemos es de mejor calidad.
Antes, sin un estandar de codificación quedaban nombres de variables en ingles y español, combinacions de mayusculas y minusculas, etc. Adicionalmente probar una actualización se volvia un dolor de cabeza, ya que no era claro que testear.
En nuestros editores (Sublime, Atom) generalmente instalamos linters o auto formateadores para que el estandar de codificación se mantenga al guardar alguna modificación.
Para aprobar nuevas cosas a producción adaptamos la metodología scrum, con la diferencia de que los sprints nuestros son semanales, mas o menos funciona así:
Los sábados en la mañana nos reunimos a revisar cómo estuvo la semana anterior y a planear la próxima semana. En la semana nos enfocamos en desarrollar hasta el jueves y parte del viernes, el mismo viernes un ingeniero aprueba lo que otro ingeniero hizo y viceversa, si hay alguna corrección se hace el mismo día, simplemente se sube el fix al repositorio y se prueba nuevamente.
Nos enfocamos en hacer desarrollos mas bien pequeños pero que aporten mucho a los software, de manera que sean más fáciles de probar por los otros ingenieros y más fáciles de subir a los servidores. De esta manera hemos garantizado que no hayan bajas de los sitios de ninguno de nuestros clientes o perdida de información.
Como modelo de ramas (Branchig model) generalmente creamos una rama por cada issue, todos los merge request creados son mezclados a una rama llamada “develop”, luego el viernes mezclamos master y develop. Si hay algun fix urgente creamos el issue del mismo, una rama y un merge request directo al master (Hotfix).
CI y CD Gitlab
Parte de nuestra política para mejorar la calidad de los software ha sido el CI y el CD, todo lo que hacemos nuevo debe tener un test (pruebas unitaria), por lo menos en backend, Gitlab (usando Docker) permite configurar de una manera muy fácil estas pruebas de manera que si un merge request tiene un error en sus test no va permitir mezclarlo (Merge) a otra rama.
El CI ha mejorado bastante la calidad de las cosas nuevas que hacemos y sobre todo ha evitado algún cambio que hagamos genere errores en otras partes donde se suponía no debía afectar.
El CD nos ha ahorrado tiempo, ya que las instancias de los proyectos en los servidores se actualizan automáticamente hay un cambio en la rama master, por ejemplo uno de nuestros proyectos llamado xShop (TIenda Virtual) tiene cerca de 9 instancias en el servidor, un cambio en el master en Gitlab automaticamente baja los cambios a las 9 instancias, instala o actualiza dependencias, corre migraciones, genera estaticos y hace un restart de cada uno de las mismas
Todo lo que es administración requiere como tal un orden para que las cosas funcionen bien, hacer seguimiento al cumplimiento de los estándares por ejemplo es muy importante, así como a los cronogramas de trabajo, lo mismo que incentivar al equipo de ingenieros para que realicen una mejora continua de los procesos y apoyarlos desde la dirección de la empresa, hasta la proxima.
Autor: Jhon J Valero R 
Ingeniero de Software en Elemental Lab
