Customer Story: Rabbit Care

Going from Pull Requests with 2,000 Lines of Code and Stalled Releases to Trunk-Based Development and Daily Deployments

We sat down with Piyush Chauhan from Rabbit Care, Thailand's largest leading financial and insurance company. Rabbit Care used to have huge releases with multiple teams getting stalled during deployments. 

They moved to trunk-based development with Flagsmith for feature flag management. Now they deploy multiple times per day to production. This means fewer overnight releases for squad leads and team members, and fewer hours spent resolving conflicts. 

Could you tell us a little bit about what you do, and what your role is at Rabbit Care?

I’m a Senior Software Engineer there. I joined the company two years ago when the company was growing fast. We had a website and agent platform in mind and new insurance products that were coming. 

I joined as Senior Front-End Developer managing the front-end team and getting new developers in. Now, we have 14 developers and a growing product suite. 

It sounds like a lot to manage! Was it that management task that made you look at feature flags?

Yes. I worked in Australia five or six years ago. When I was there, I learned that having a smooth process for managing branches makes it much easier to deliver products faster.

When I joined Rabbit Care, people were using GitFlow and we had multiple branches, which made it really hard to manage and merge pull requests (PRs). So I decided to move us to trunk-based development.

And to go with trunk-based development, we had to use feature flags. With trunk-based development, you have your core trunk of code and then branches segment off of that as you release new things in your product line. And feature flags are crucial. 

The company was a growing startup, and we were willing to experiment with lower-budget feature flagging solutions. I went through multiple solutions and in-house options, and Flagsmith was one of them.

What made you choose trunk-based development?

In my first two weeks, I saw a couple of big PRs averaging around 2,000 lines of code.

Back then, everybody worked to deliver smaller features, but nothing was delivered. It would take months to resolve things like those big PRs. So I realised, “Oh this cannot go on. Who likes to stay up at night and manage all of this?”

Those are big PRs! What did you weigh up when you were looking at building in-house versus using a vendor?

We were considering an in-house solution because price was a factor and we weren’t sure about paying a vendor. 

But also, if you build an in-house solution, you have to implement all the authentication and manage server uptimes. And it doesn't make any sense, right? 

Right! And what has changed the most for you and your releases since you’ve changed your workflows and setup?

We follow the Spotify product development model now, which splits the team into different squads. We have seven squads, each headed by tech leads.

Previously, we had to come together and do overnight sessions for releases because there was no simple process to release. 

Now, we push forward and implement. We deploy all the time in production. So whenever stakeholders want, they can review the releases. 

We have multiple deployments, with an average rate of at least four deployments per day in production.

It depends on the stakeholders, but often QA gives the green light and then the stakeholders will say things are ready to go live and become visible. 

Now the team doesn't have to do overnights. We don't have to solve conflicts all day. It’s much easier.

It sounds like it's made your team’s work a lot easier. And four deploys per day in production; how does that compare to when you started at Rabbit?  

So what I can compare to is our process in GitFlow. 

We had the development branch. And then everybody was waiting on that branch. Our team used to prepare big branches and then wait for the signal that we were ready to release. 

Let's say we had seven teams and seven branches waiting to deploy. One would deploy and then the next would try to deploy. But they couldn’t. There was no integration. So they would say that they had conflicting changes. 

The teams would have to resolve all the conflicting changes, which could take four or five hours. And sometimes we couldn’t even resolve the changes because every line was not integrated continuously.

So we had to go back and queue again.

This was just one team being stopped. After that, they would merge and the next team would come in, and they would have the same problems. This resulted in a lot of wasted efforts and resources. 

That sounds like a lot.

It was. So now we continuously merge, which means the team doesn't have to do all of that conflict management. And the deployments are every day instead of waiting for special release sessions.

That’s huge! If someone moved into the role you were in two years ago, what would your advice be for them for managing their releases?

First, I would recommend analysing the whole problem before jumping straight onto feature flagging software. Or even feature flags. Instead, go and see what the branches look like, what people are doing, how releases look, and how JIRA and sprints are going. 

If there is a problem with these factors, then try trunk-based development. It definitely helps. And if you are happy with trunk-based development, you need feature flags. Which means you have to search for feature flag solutions. And Flagsmith is one of the good ones.

Now that you're using Flagsmith, what are some of the things that work for you?

I definitely like the model because it’s very easy to understand. Then there’s the open source piece, which means that we can navigate through the codebase and recommend improvements to the codebase or user interface. We can check the roadmap, look at issues, and everything is transparent. 

The Edge API definitely worked out for us, too. The Edge was a major move and definitely helped us quite a lot. 

Also, the update panel that got introduced works for us. It's easier to get notifications and know that updates are there and it’s all visible. 

And how are your team finding the new feature flag workflows? 

The teams collaborate more often, which is a huge value for us. 

Feature flags don’t directly generate money, but you can see the business value. Before, things used to be delayed all the time and there was a lot to manage. 

For example, we have mobile applications. With mobile apps, you need to release changes more frequently as the scale of business and products grows, and as products need to be made available to different types of customers. 

For those releases, you’ll have to publish in the PlayStore or AppStore, which can take a day if the application is pre-approved and the continuous delivery pipeline is already set up. The publish also has to go through TestFlight where QA and stakeholders can test, after which it can take 24 hours for the approved changes to be visible in the AppStore. Without feature flagging, this process can be pretty cumbersome for the whole team.

Also, when it comes to serious bugs that could result in loss of revenue, feature flagging makes it easier to turn off portions of the app or website. Sometimes this can also result in a serious impact on SEO, so having kill switches with a feature flagging solution can help to mitigate these aspects. 

Thank you so much for your time and business, Piyush!

If you’d like to find out more about how Flagsmith could work with your teams, start by creating a free account, or contact us to find out more about on-premises hosting and more.