El Viaje de ING en la Construcción e Implementación de Código Front-end

En los últimos ocho años, hemos estado tratando de adaptar estos pipelines a las necesidades de nuestra organización y me gustaría llevarlos en este recorrido durante esta presentación. El primer paso que dimos fue simplemente probar el código de front-end dentro de ING. Lo implementamos en cualquier servidor web disponible o en un CMS. Cada equipo tenía su propia solución. No reutilizábamos nada y debido al crecimiento en el uso, decidimos buscar una mejor solución.

Entonces, dentro de ING, decidimos introducir nuestro pipeline de Angular. El pipeline se basaba en aplicaciones de Angular y podía recoger cada confirmación de desarrollo y master. Y aplicamos una configuración específica para tu aplicación. Esto significa que todos los pasos en tu construcción estaban predefinidos. Así que solo tenías un sabor. Implementamos los resultados de la construcción a intervalos regulares en pruebas y aceptación. Y al menos una vez al día íbamos a producción. El resultado de eso fue que pudimos servir más de 700 módulos. Pudimos reutilizar. Así que esto nos brindó un pipeline que nos permitió reutilizar bibliotecas y nos acercó a la entrega continua. Servimos alrededor de 700 módulos. Podíamos reutilizar cosas.

Pero nuestros equipos demandaban ser un poco menos restrictivos. Por ejemplo, en los métodos de pruebas que podían usar en la herramienta de construcción. Y también queríamos tener estas enormes bibliotecas que no tenían versión. Y si teníamos que actualizar una de estas bibliotecas, teníamos que volver a implementar y probar cada aplicación en nuestro pipeline. Si solo tienes dos o tres aplicaciones, está bien. Pero si estás sirviendo más de 160 aplicaciones, ya no es divertido. Así que decidimos buscar una mejor solución. Después de eso, introdujimos dentro de ING nuestro pipeline de Polymer basado en aplicaciones y componentes web. Pudimos construir e implementar en pruebas en cada confirmación. Y proporcionamos un portal a nuestros equipos en el que podían gestionar las versiones que se implementaron en aceptación y producción.

Y lo que ese portal también hizo fue hacer visible cada componente web que se desarrolló dentro de ING. Y fue visible para todos los equipos. Por lo tanto, realmente permitió la reutilización de componentes web dentro de ING.

Para esto, los equipos utilizaron nuestra ING web CLI, que desarrollamos nosotros mismos. Y esa es una interfaz de línea de comandos en la que todas las tareas posibles como construcción, prueba, instalación, implementación, lo que sea, se capturaron dentro de esa web CLI. Los equipos podían elegir lo que necesitaban de esa CLI, pero había una desventaja. Si no lo incluíamos en la CLI, no podían usarlo. Por lo tanto, era restrictivo en el sentido de que solo podían usar lo que desarrollamos, pero al menos tenían alguna opción en cómo incluir el contenido en su construcción.

Entonces todavía era un poco restrictivo, y es por eso que decidimos encontrar una mejor solución. Y ahí es donde estamos actualmente. Nos mudamos a Azure DevOps. Y actualmente estamos creando nuestros pipelines basados en plantillas. Y si no podemos adaptarlo a una plantilla, entonces lo convertimos en una tarea personalizada. Y los equipos pueden utilizar estas plantillas si lo desean. Y también pueden utilizar cualquier otra cosa que deseen. La migración está en curso hacia ese pipeline. Y para nosotros, la gran ventaja es que los equipos pueden usar otras cosas que no les proporcionamos. Esto les permite innovar en la forma en que construyen sus aplicaciones. Y para nosotros, es una ventaja que podemos poner esas innovaciones a disposición de otros equipos mediante la creación de nuevas plantillas y nuevas tareas personalizadas.

Entonces, este es el camino que recorrimos dentro de ING para nuestros pipelines. Lo primero que hicimos fue simplemente quitar la carga de construcción e implementación de los equipos para que pudieran avanzar más rápido. El impulsor aquí fue la agilidad. El segundo paso fue que queríamos darles a los equipos más libertad de elección y permitir la escalabilidad, para poder entregar más aplicaciones en nuestros pipelines. Y el último paso que dimos fue la autonomía. Por lo tanto, permitimos a los equipos hacer lo que quisieran y ayudarlos al hacerlo, lo que llevó a más innovación, y creo que el impulsor aquí es la autonomía. Si miras tu organización, puede ser completamente diferente. Para nosotros, nuestros impulsores fueron menos rigidez, más agilidad, más escala, más autonomía. Pero para tu organización, pueden ser impulsores como la madurez del equipo, la confianza, tal vez incluso algo tan simple como el número de equipos u cualquier otro impulsor que no se me ocurra, y tal vez a ti sí. Por lo tanto, la lección es elegir los impulsores adecuados, utilizar esos impulsores para adaptar tus pipelines a tu organización. Te deseo buena suerte con eso. Gracias por tu atención.