ING’s Journey in Building and Deploying Frond-end Code

Rate this content

Within ING we have been dealing with JS/FE for quite some years now. Starting with nothing we evaluated the CI/CD process for this, via multiple stages into what it is right now. I will go along these stages to inspire you to create a similar process for your own company.

8 min
01 Jul, 2021

AI Generated Video Summary

The Fruit Loops team at ING aims to simplify the lives of front-end engineers by introducing pipelines. They started with an Angular pipeline and then introduced a Polymer pipeline based on apps and web components. The ING web CLI and Azure DevOps were used to create pipelines that provided agility, freedom of choice, scaling, and autonomy to teams. The key takeaway is to choose the right drivers to fit your organization's needs when implementing pipelines.

1. Introduction to Fruit Loops team and Pipelines

Short description:

Hi, everyone. My name is Eric van der Voort and I'm one of the engineers of the Fruit Loops team within ING. The main goal of the Fruit Loops team within ING is to make the life of front-end engineers easier. In the past eight years, we have been trying to fit these pipelines into the needs of our organization. We introduced our Angular pipeline and were able to serve more than 700 modules, enabling us to reuse libraries. However, our teams demanded a less restrictive solution, leading us to introduce our Polymer pipeline based on apps and web components.

Hi, everyone. My name is Eric van der Voort and I'm one of the engineers of the Fruit Loops team within ING. The main goal of the Fruit Loops team within ING is to make the life of front-end engineers easier and that's why this team has a history in pipelines for building and deploying front-end code within ING.

In the past eight years, we have been trying to fit these pipelines into the needs of our organization and the journey that we traveled, I would like to take you along in this presentation. The first step we made was just trying out front-end code within ING. We deployed it on any available web server or in CMS. Every team had its own solution. We didn't do any reuse and because the usage was growing, we decided to come up with a better solution.

So within ING, we decided to introduce our Angular pipeline. The pipeline was based on Angular applications and was able to pick up every commit from develop and master. And we enforced a certain setup for your application. And that means that all the steps in your build were predefined. So you just have one flavor. We deployed the results of the build on a regular interval on test and acceptance. And at least once a day we went to production. The result of that was that we were able to serve more than 700 modules. We were able to reuse. So this brought us a pipeline that enabled us to reuse libraries, and it was almost getting us in the direction of continuous delivery. We served about 700 modules. We could reuse stuff.

But our teams were demanding to be a little bit less restrictive. For example, on the testing methods, they could use in the build tooling. And what we also wanted is that we had these huge libraries that were not versioned. And if we had to update one of these libraries, we had to redeploy and test every application in our pipeline. If you only have two or three applications, that's fine. But if you are serving more than 160 applications, it's not funny anymore. So that's why we decided to come up with a better solution. So after that, we introduced within ING our Polymer pipeline based on apps and web components. We were able to build and deploy to test on every commit. And we provided a portal to our teams in which they could manage the versions that were deployed on acceptance and production.

2. ING Pipeline Journey

Short description:

The portal made every web component developed within ING visible to all teams, enabling their reuse. Teams used our ING web CLI, a command line interface capturing build, test, install, deploy tasks. However, it was restrictive, so we moved to Azure DevOps, making pipelines based on templates. Teams can use templates and innovate with new custom tasks. Our journey focused on agility, freedom of choice, scaling, and autonomy. Choose the right drivers to fit your pipelines into your organization.

And what that portal also did was that it made visible every web component that was developed within ING. And it was visible for all the teams. So it really enabled the reuse of web components within ING.

For this, the teams used our ING web CLI, what we developed ourselves. And that is a command line interface in which all the possible tasks like build, test, install, deploy, whatever, they were captured inside that web CLI. The teams could pick whatever they need from that CLI, but there was one downside. If we didn't put it in the CLI, they were not able to use it. So it was restrictive in a way that they could only use what we developed, but they could at least have some choice in how they put the content in their build.

So it was still a little bit too restrictive, and that is why we decided to come up with a better solution. And that's where we are currently now. So we moved to Azure DevOps. And currently we are making our pipelines based on templates. And if we cannot fit it into a template, then we make it a custom task. And teams can use these templates if they like. And they can also use whatever else they want to use. The migration is currently ongoing into that pipeline. And for us, the big advantage is that teams can use other things that we didn't provide to them. So it enables them to innovate the way they are building their applications. And for us, it's an advantage that we can make those innovations available for other teams by putting them into new templates and new custom tasks.

So this is kind of the way that we traveled within ING for our pipelines. The first thing we did was actually just take the burden of build and deploy away from the teams so they could move faster. So the driver here was agility. The second step was that we wanted to give the teams more freedom of choice and enable scaling, so we were able to deliver more applications in our pipelines. And the last step that we made was autonomy. So we enabled the teams to do whatever they wanted and helping them by doing that, so more innovation, and I think that the driver for there is autonomy. If you look at your organization, it might be completely different. For us, our drivers were less strictness, more agility, more scale, more autonomy. But for your organization, it might be drivers like team maturity, trust, maybe even just a simple thing like the number of teams or any other driver that I cannot think of, and maybe you can. So the takeaway is pick your right drivers, use those drivers to fit your pipelines into your organization. And I wish you good luck with that.

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
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
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.
DevOps.js Conf 2022DevOps.js Conf 2022
33 min
Fine-tuning DevOps for People over Perfection
Demand for DevOps has increased in recent years as more organizations adopt cloud native technologies. Complexity has also increased and a "zero to hero" mentality leaves many people chasing perfection and FOMO. This session focusses instead on why maybe we shouldn't adopt a technology practice and how sometimes teams can achieve the same results prioritizing people over ops automation & controls. Let's look at amounts of and fine-tuning everything as code, pull requests, DevSecOps, Monitoring and more to prioritize developer well-being over optimization perfection. It can be a valid decision to deploy less and sleep better. And finally we'll examine how manual practice and discipline can be the key to superb products and experiences.

Workshops on related topic

React Summit Remote Edition 2021React Summit Remote Edition 2021
87 min
Building a Shopify App with React & Node
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
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
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
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.
DevOps.js Conf 2022DevOps.js Conf 2022
13 min
Azure Static Web Apps (SWA) with Azure DevOps
Azure Static Web Apps were launched earlier in 2021, and out of the box, they could integrate your existing repository and deploy your Static Web App from Azure DevOps. This workshop demonstrates how to publish an Azure Static Web App with Azure DevOps.