May 22, 2019
-
Tech

Comenzando Nuestro Camino hacia la Integración Continua

L

a integración continua (CI, por la sigla en Inglés, Continuous Integration) es una práctica de desarrollo de software que combina y verifica constantemente el código proporcionado por un equipo de programadores o ingenieros. Es diferente de lo que se hacía antes, ya que las personas en un equipo de desarrollo trabajarían en su entorno local, enviarían el código a un repositorio y alguien probaría, validaría y fusionaría los cambios.

La forma en que la Integración Continua está impactando la creación de valor en el Software es muy importante, ya que puede reducir el tiempo ingreso al mercado para los equipos mientras aumenta dramáticamente la calidad del trabajo. Los ciclos de desarrollo son más cortos, lo que significa que un equipo puede detectar problemas antes de que se vuelvan inmanejables, y los controles son automáticos, lo que libera a las personas de esta tarea.

Claramente estamos perdiendo tiempo y recursos al tener diferentes entornos y sin automatización. Fuente: Zend

Cuando llegué por primera vez a Interlink, en Noviembre de 2018, tuve la tarea de liderar el cambio en Investigación y Desarrollo (I+D). Mi primera misión fue reconocer las estructuras y procesos existentes, observando y aprendiendo cuáles eran los procesos implementados para luego poder mejorarlos. Esta etapa inicial me llevó dos meses.

Fue difícil porque me mudé de Brasil a las oficinas de Interlink en Rosario, Argentina, sin hablar una palabra de español y teniendo que liderar un equipo de desarrolladores. Pero perseveré, interactuando en Inglés siempre que era posible.

A medida que aprendí cómo funcionaba todo, encontré útil anotar los cambios que queríamos ver, incluso cuando los detalles eran confusos. Me pidieron que mantuviera la mente abierta y que volviera a imaginar los procesos en lugar de adaptarme a ellos. Naturalmente, la mayoría de mis notas fueron sobre el flujo de trabajo y el uso de tecnologías.

El primer obstáculo a superar fue reemplazar a Jira con algo que podría ser más simple y mejor para esta nueva etapa.

Implementando nuevos flujos de trabajo junto con un nuevo Issue Tracker

En Software, un problema o inconveniente es un Issue, y existen líneas generales de cómo documentar esto para que sea reproducible y tratable para ser resuelto. Generalmente el software que nos ayuda a crear software tiene un componente de seguimiento de Issues, lo que se llama un Issue Tracker.

Durante los primeros meses en Interlink, la compañía estaba usando Atlassian para el desarrollo de software y herramientas de colaboración. Las herramientas de Atlassian son muy buenas y representan una solución completa para las compañías de desarrollo de software.

¿Sabes la sensación cuando ves una chaqueta increíble en una tienda y luego, cuando te la pruebas, te das cuenta de que no te queda bien? Así es como nos sentimos al usar Atlassian, sabíamos que era bueno, pero simplemente no nos quedaba bien.

En Septiembre de 2018, previo a mi desembarco en Rosario, tuve una charla con el equipo de administración sobre una presentación de GitLab que me pareció muy interesante. Nuestra principal conclusión después de ver ese webcast fue que el objetivo de GitLab es hacer que los desarrolladores contribuyan más rápido y tengan ciclos de trabajo (sprints) más pequeños. También me impresionó mucho su tasa de crecimiento (200% por año). Entonces, después de hablar sobre esto, decidimos comenzar a usar GitLab solo para ver cómo funciona y para ver si se ajustaba a nuestras necesidades.

Después de las pruebas iniciales, se nos ocurrió un plan de lo que debíamos hacer antes de implementar GitLab, en términos generales:

1. Aprender y adoptar las mejores prácticas

2. Importar todo lo que teníamos (y necesitábamos) desde BitBucket, una solución de hospedaje de repositorios de Atlassian.

3. Usar proyectos con fechas límite e hitos para mantener todo en orden.

GitLab proporciona claramente una manera de no solo administrar ordenadamente el trabajo basado en repositorios, sino también las pipelines de CI.

Así que, como un proceso aparte de GitLab, decidimos primero mejorar el flujo de trabajo de desarrollo. Lo hicimos definiendo todas las reglas y metodologías que esperamos que nuestro equipo siga. Parecía tedioso a veces, pero teníamos la sensación de que iba a ser una referencia importante para hacer que el cambio se mantuviera.

Al final de este proceso, obtuvimos un flujo de trabajo sólido y estábamos listos para presentar los cambios al equipo.

Así abordamos la transición de frente y comenzamos a usar GitLab en enero de 2019, moviendo los proyectos más pequeños de Atlassian a su nuevo hogar, ajustando diferentes preferencias para nuestro flujo de trabajo, todo mientras aún realizamos pruebas bajo el plan gratuito.

Nos tomó ese mes completo migrar todo y ajustar nuestras herramientas de integración continua. Febrero comenzó con nosotros usando su versión de prueba gratuita por 30 días, del plan Gold. Y con eso identificamos qué herramientas necesitábamos.

Nos abrió los ojos porque ya podíamos sentirnos mucho más organizados y cómodos de lo que alguna vez aspiramos a estar bajo el conjunto de herramientas de Atlassian.

Incluso con nuestra planificación, antes de la implementación, tuvimos que enfrentar nuevos desafíos durante nuestros primeros meses. Por ejemplo, hasta este momento, GitLab aún no permite solicitudes de combinación entre repositorios, por lo que tuvimos que agregar a nuestro proceso un patrón manual para las solicitudes de combinación.

Otro problema que tuvimos fue la cuota de Pipelines, que en nuestro plan actual es de 2.000 minutos al mes, y fue excedida muy rápido debido a la complejidad de uno de nuestros proyectos. Por ello tuvimos que tener nuestro propio pipeline en un servidor local solo para ese proyecto, mientras que los otros siguieron usando el pipeline de GitLab.

Tecnologías

Los sistemas de Interlink involucran principalmente una gran cantidad de datos relacionados con el tráfico del Protocolo de Internet (IP). Dado que la compañía tiene soluciones de software que ayudan a los proveedores de servicios de Internet (ISP) a hacer su trabajo de manera más eficiente, hay una gran cantidad de datos relacionados con una buena provisión de servicios de Internet, incluidas las estadísticas de administración de redes. Por lo general, debemos ingresar y mostrar estos datos lo más rápido posible para proporcionar estadísticas, geolocalización, registros de acceso o entradas de equipos.

Cuando llegué a la empresa, la mayoría de los sistemas estaban escritos en PHP utilizando MySQL como base de datos, pero la compañía tenía un objetivo claro de pasar de estos a una tecnología más moderna. Por lo tanto, tuvimos dos nuevos proyectos que debería liderar con el equipo: Assist HR y Strings. Para estos dos decidimos no solo usar una tecnología diferente, sino también hacer las cosas de un modo distinto.

En Assist HR, uno puede manejar la resolución de conflictos de relaciones laborales. El prototipo nos dio un camino claro hacia adelante.

Ambos proyectos ya tenían su etapa conceptual lista, se encontraban en la fase de prototipo funcional. Assist HR fue un prototipo que utilizaba NodeJS como backend y jQuery en el frontend con MongoDB para la base de datos. El plan era reconstruir Assist HR con React y un backend mejorado. Y eso fue exactamente lo que hicimos.

El uso de jQuery fue temporal, diseñado para tener un prototipo rápido que probaría la propuesta de valor principal y los casos de uso. Pero ¿por qué cambiamos de jQuery a React? Podría continuar escribiendo un artículo completo sobre esto, pero aquí hay algunos breves aspectos clave sobre React que nos llamaron la atención:

- Simplicidad

    El uso de JavaScript y el enfoque basado en componentes hacen que React sea muy fácil de aprender. Teníamos un equipo en transición.

- Reutilización

    React es una plataforma. Los componentes están a solo una instalación de npm / yarn de distancia, por lo que esto facilita compartirlos, lo cual es una ventaja que aumenta con el tiempo. Ahora podemos tener fácilmente los componentes desarrollados en un proyecto e importarlos a otro.

- Rendimiento

    Al usar un Modelo de Objeto de Documento (DOM) virtual, React procesa todo en JavaScript y luego modifica solo las cosas que cambiaron en el DOM real.

Strings, una solución para el monitoreo de redes y estadísticas, también se beneficia de esta nueva arquitectura y ciclos de desarrollo más rápidos. Una de las principales limitaciones que evidenciamos con PHP y MySQL fue que cada vez que teníamos que cargar dispositivos de red en un mapa, los requisitos de hardware eran importantes, ya que era el tiempo de carga era muy lento cuando el número de elementos era grande.

Bajo NodeJS, pudimos confirmar que su naturaleza asíncrona es ideal para esto. En lugar de cargar los objetos del mapa uno por uno, que es lo que nos veíamos obligados a hacer con PHP, ahora podemos cargar los componentes de una vez. Esto reduce en gran medida nuestro tiempo de carga y quita la presión sobre nuestros recursos de procesamiento.

El plan ahora es adoptar este mismo enfoque para FiberMaps, una solución de planificación y documentación de red que le permite diseñar una red de suministro de Internet utilizando objetos predefinidos, de manera que uno sólo debe arrastrar y soltar elementos en el mapa. Esto es útil para que las empresas puedan geo-referenciar sus dispositivos de red, planificar cambios y hacer que el personal nuevo comprenda la estructura de lo que se hizo anteriormente, impactando la facilidad de resolución de problemas.

FiberMaps permite a los ISPs documentar sus redes, lo que permite una gran planificación y referencia para solucionar problemas.

Funcionalidades Avanzadas de GitLab

Una cosa que investigamos y nos gustó mucho es el potencial detrás de la Integración Continua (CI). Básicamente, CI es una práctica de desarrollo que implica que el desarrollador inserte el código diariamente en un repositorio compartido, y este código se verifica mediante una compilación automatizada que le permite al equipo detectar problemas en forma temprana.

Podemos hacer mucho con CI, en este momento lo estamos utilizando para hacer deploys (entregas, migraciones de código) automáticos en nuestro entorno de prueba, con controles configurados para asegurarnos de que todo esté a la altura de las especificaciones.

Una forma clara de visualizar la estructura de GitLab para CI / CD. Fuente: Gitlab.com

También compartimos esto con diferentes personas fuera del equipo de desarrollo, por ejemplo, nuestro software de aprovisionamiento de redes, Flowdat, confirma automáticamente los últimos cambios en nuestro repositorio local de Gogs. Genera imágenes de Docker, imágenes de versión y establece una instancia del proyecto para ejecutar una serie de pruebas programadas.

Nuestro próximo objetivo es que el servidor de CI ejecute las compilaciones de código y haga las pruebas de unidad e integración, para garantizar la calidad del código. Sabemos que las cosas cambian rápidamente en la tecnología, y tenemos que adoptar hoy el mix de soluciones que pueden satisfacer nuestras necesidades actuales. Es un objetivo en movimiento, pero es una búsqueda incesante que nos apasiona.

Compartir nuestro pensamiento sobre la arquitectura del software nunca debe ser prescriptivo ni universal, ya que la utilidad de implementación depende de su equipo, el momento de desarrollo en el que se encuentre y las limitaciones con las que está trabajando. Pero encontramos que compartir la mentalidad detrás de nuestros cambios siempre ayuda a proporcionar una nueva perspectiva. Consulte nuevamente HyperConnect para obtener más información sobre nuestros procesos de ingeniería y futuros diarios de desarrollo.

-Markson Rebelo Marcolino