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

Rate this content
Bookmark

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.

Erik van der Voort
Erik van der Voort
8 min
01 Jul, 2021

Comments

Sign in or register to post your comment.

Video Summary and Transcription

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

Levelling up Monorepos with npm Workspaces
DevOps.js Conf 2022DevOps.js Conf 2022
33 min
Levelling up Monorepos with npm Workspaces
Top Content
Learn more about how to leverage the default features of npm workspaces to help you manage your monorepo project while also checking out some of the new npm cli features.
A Framework for Managing Technical Debt
TechLead Conference 2023TechLead Conference 2023
35 min
A Framework for Managing Technical Debt
Top Content
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.

Debugging JS
React Summit 2023React Summit 2023
24 min
Debugging JS
Top Content
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.
Automating All the Code & Testing Things with GitHub Actions
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.
Building a Voice-Enabled AI Assistant With Javascript
JSNation 2023JSNation 2023
21 min
Building a Voice-Enabled AI Assistant With Javascript
Top Content
In this talk, we'll build our own Jarvis using Web APIs and langchain. There will be live coding.
Power Fixing React Performance Woes
React Advanced Conference 2023React Advanced Conference 2023
22 min
Power Fixing React Performance Woes
Top Content
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

Building a Shopify App with React & Node
React Summit Remote Edition 2021React Summit Remote Edition 2021
87 min
Building a Shopify App with React & Node
Top Content
WorkshopFree
Jennifer Gray
Hanna Chen
2 authors
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.
Build a chat room with Appwrite and React
JSNation 2022JSNation 2022
41 min
Build a chat room with Appwrite and React
WorkshopFree
Wess Cope
Wess Cope
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!
Hard GraphQL Problems at Shopify
GraphQL Galaxy 2021GraphQL Galaxy 2021
164 min
Hard GraphQL Problems at Shopify
WorkshopFree
Rebecca Friedman
Jonathan Baker
Alex Ackerman
Théo Ben Hassen
 Greg MacWilliam
5 authors
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.
Deploying React Native Apps in the Cloud
React Summit 2023React Summit 2023
88 min
Deploying React Native Apps in the Cloud
WorkshopFree
Cecelia Martinez
Cecelia Martinez
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.
MERN Stack Application Deployment in Kubernetes
DevOps.js Conf 2022DevOps.js Conf 2022
152 min
MERN Stack Application Deployment in Kubernetes
Workshop
Joel Lord
Joel Lord
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.