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

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.

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.