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

Rate this content
Bookmark

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.

8 min
01 Jul, 2021

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

TechLead Conference 2023TechLead Conference 2023
35 min
A Framework for Managing Technical Debt
Let’s face it: technical debt is inevitable and rewriting your code every 6 months is not an option. Refactoring is a complex topic that doesn't have a one-size-fits-all solution. Frontend applications are particularly sensitive because of frequent requirements and user flows changes. New abstractions, updated patterns and cleaning up those old functions - it all sounds great on paper, but it often fails in practice: todos accumulate, tickets end up rotting in the backlog and legacy code crops up in every corner of your codebase. So a process of continuous refactoring is the only weapon you have against tech debt.In the past three years, I’ve been exploring different strategies and processes for refactoring code. In this talk I will describe the key components of a framework for tackling refactoring and I will share some of the learnings accumulated along the way. Hopefully, this will help you in your quest of improving the code quality of your codebases.

React Summit 2023React Summit 2023
24 min
Debugging JS
As developers, we spend much of our time debugging apps - often code we didn't even write. Sadly, few developers have ever been taught how to approach debugging - it's something most of us learn through painful experience.  The good news is you _can_ learn how to debug effectively, and there's several key techniques and tools you can use for debugging JS and React apps.
React Advanced Conference 2021React Advanced Conference 2021
19 min
Automating All the Code & Testing Things with GitHub Actions
Top Content
Code tasks like linting and testing are critical pieces of a developer’s workflow that help keep us sane like preventing syntax or style issues and hardening our core business logic. We’ll talk about how we can use GitHub Actions to automate these tasks and help keep our projects running smoothly.
React Advanced Conference 2022React Advanced Conference 2022
22 min
Monolith to Micro-Frontends
Top Content
Many companies worldwide are considering adopting Micro-Frontends to improve business agility and scale, however, there are many unknowns when it comes to what the migration path looks like in practice. In this talk, I will discuss the steps required to successfully migrate a monolithic React Application into a more modular decoupled frontend architecture.
React Advanced Conference 2023React Advanced Conference 2023
22 min
Power Fixing React Performance Woes
Next.js and other wrapping React frameworks provide great power in building larger applications. But with great power comes great performance responsibility - and if you don’t pay attention, it’s easy to add multiple seconds of loading penalty on all of your pages. Eek! Let’s walk through a case study of how a few hours of performance debugging improved both load and parse times for the Centered app by several hundred percent each. We’ll learn not just why those performance problems happen, but how to diagnose and fix them. Hooray, performance! ⚡️

Workshops on related topic

React Summit Remote Edition 2021React Summit Remote Edition 2021
87 min
Building a Shopify App with React & Node
Top Content
WorkshopFree
Shopify merchants have a diverse set of needs, and developers have a unique opportunity to meet those needs building apps. Building an app can be tough work but Shopify has created a set of tools and resources to help you build out a seamless app experience as quickly as possible. Get hands on experience building an embedded Shopify app using the Shopify App CLI, Polaris and Shopify App Bridge.We’ll show you how to create an app that accesses information from a development store and can run in your local environment.
JSNation 2022JSNation 2022
41 min
Build a chat room with Appwrite and React
WorkshopFree
API's/Backends are difficult and we need websockets. You will be using VS Code as your editor, Parcel.js, Chakra-ui, React, React Icons, and Appwrite. By the end of this workshop, you will have the knowledge to build a real-time app using Appwrite and zero API development. Follow along and you'll have an awesome chat app to show off!
GraphQL Galaxy 2021GraphQL Galaxy 2021
164 min
Hard GraphQL Problems at Shopify
WorkshopFree
At Shopify scale, we solve some pretty hard problems. In this workshop, five different speakers will outline some of the challenges we’ve faced, and how we’ve overcome them.

Table of contents:
1 - The infamous "N+1" problem: Jonathan Baker - Let's talk about what it is, why it is a problem, and how Shopify handles it at scale across several GraphQL APIs.
2 - Contextualizing GraphQL APIs: Alex Ackerman - How and why we decided to use directives. I’ll share what directives are, which directives are available out of the box, and how to create custom directives.
3 - Faster GraphQL queries for mobile clients: Theo Ben Hassen - As your mobile app grows, so will your GraphQL queries. In this talk, I will go over diverse strategies to make your queries faster and more effective.
4 - Building tomorrow’s product today: Greg MacWilliam - How Shopify adopts future features in today’s code.
5 - Managing large APIs effectively: Rebecca Friedman - We have thousands of developers at Shopify. Let’s take a look at how we’re ensuring the quality and consistency of our GraphQL APIs with so many contributors.
DevOps.js Conf 2022DevOps.js Conf 2022
152 min
MERN Stack Application Deployment in Kubernetes
Workshop
Deploying and managing JavaScript applications in Kubernetes can get tricky. Especially when a database also has to be part of the deployment. MongoDB Atlas has made developers' lives much easier, however, how do you take a SaaS product and integrate it with your existing Kubernetes cluster? This is where the MongoDB Atlas Operator comes into play. In this workshop, the attendees will learn about how to create a MERN (MongoDB, Express, React, Node.js) application locally, and how to deploy everything into a Kubernetes cluster with the Atlas Operator.
React Summit 2023React Summit 2023
88 min
Deploying React Native Apps in the Cloud
WorkshopFree
Deploying React Native apps manually on a local machine can be complex. The differences between Android and iOS require developers to use specific tools and processes for each platform, including hardware requirements for iOS. Manual deployments also make it difficult to manage signing credentials, environment configurations, track releases, and to collaborate as a team.
Appflow is the cloud mobile DevOps platform built by Ionic. Using a service like Appflow to build React Native apps not only provides access to powerful computing resources, it can simplify the deployment process by providing a centralized environment for managing and distributing your app to multiple platforms. This can save time and resources, enable collaboration, as well as improve the overall reliability and scalability of an app.
In this workshop, you’ll deploy a React Native application for delivery to Android and iOS test devices using Appflow. You’ll also learn the steps for publishing to Google Play and Apple App Stores. No previous experience with deploying native applications is required, and you’ll come away with a deeper understanding of the mobile deployment process and best practices for how to use a cloud mobile DevOps platform to ship quickly at scale.