Dentro de ING hemos estado trabajando con JS/FE durante varios años. Comenzando desde cero, evaluamos el proceso de CI/CD para esto, pasando por múltiples etapas hasta llegar a lo que es ahora. Voy a repasar estas etapas para inspirarte a crear un proceso similar para tu propia empresa.
Video Summary and Transcription
El equipo Fruit Loops de ING tiene como objetivo simplificar la vida de los ingenieros front-end mediante la introducción de pipelines. Comenzaron con un pipeline de Angular y luego introdujeron un pipeline de Polymer basado en aplicaciones y componentes web. Se utilizaron el ING web CLI y Azure DevOps para crear pipelines que brindaron agilidad, libertad de elección, escalabilidad y autonomía a los equipos. La lección principal es elegir los controladores adecuados que se adapten a las necesidades de tu organización al implementar pipelines.
Available in English
1. Introducción al equipo Fruit Loops y a los Pipelines
Short description:
Hola a todos. Mi nombre es Eric van der Voort y soy uno de los ingenieros del equipo Fruit Loops dentro de ING. El objetivo principal del equipo Fruit Loops dentro de ING es facilitar la vida de los ingenieros de front-end. En los últimos ocho años, hemos estado tratando de adaptar estos pipelines a las necesidades de nuestra organización. Introdujimos nuestro pipeline de Angular y pudimos servir más de 700 módulos, lo que nos permitió reutilizar bibliotecas. Sin embargo, nuestros equipos demandaban una solución menos restrictiva, lo que nos llevó a introducir nuestro pipeline de Polymer basado en aplicaciones y componentes web.
Mi nombre es Eric van der Voort y soy uno de los ingenieros del equipo Fruit Loops dentro de ING. El objetivo principal del equipo Fruit Loops dentro de ING es facilitar la vida de los ingenieros de front-end y es por eso que este equipo tiene experiencia en pipelines para construir e implementar código de front-end dentro de ING.
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.
2. ING Pipeline Journey
Short description:
El portal hizo que cada componente web desarrollado dentro de ING fuera visible para todos los equipos, permitiendo su reutilización. Los equipos utilizaron nuestra ING web CLI, una interfaz de línea de comandos que captura las tareas de construcción, prueba, instalación e implementación. Sin embargo, era restrictivo, por lo que nos mudamos a Azure DevOps, creando pipelines basados en plantillas. Los equipos pueden utilizar plantillas e innovar con nuevas tareas personalizadas. Nuestro viaje se centró en la agilidad, la libertad de elección, la escalabilidad y la autonomía. Elija los controladores adecuados para adaptar sus pipelines a su organizació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.
