Best Way to Add New Features to a Production Web App

Questions
1

Since most users can request new features to a production app, does anyone know of the safest way to add new features to an already existing app without breaking other parts of the app?

Thanks

1 Like
2

Hi there, @divine.tmaredi… as I’m sure you can imagine, there isn’t a single answer or a right answer to your question. That being said, here are some thoughts that I hope will be helpful, and they are based on a long career in software development as well as two years of hands-on app building in Bubble.

  • Have the person/people who are adding the features be the person/people who built the app in the first place. Nobody will know the ways in which the pieces of an app work together better than the folks who built those pieces from the ground up, and their knowledge is worth its weight in gold when it comes to making sure everything continues to work as new features are added.
  • Testing, testing, and more testing. Whether it be manual or via an automated framework, you must thoroughly test a new feature before deploying it to production. However, testing only the new feature isn’t enough; you need to test “around” the new feature, too. Think about the parts of the app that interact in any way, shape, or form with the new feature, and thoroughly test those areas, too.
  • Walk through different use cases and user scenarios. When you add a new feature, you probably have a pretty specific user/use case in mind, and it can be easy to narrow your focus to only that user/use case. To avoid falling into that mindset, ask yourself how different users will experience the new feature, and make sure you walk through those scenarios. For example, what will the new feature look like to a brand new user? A user with some data in the app? A user with lots of data in the app? Etc.
  • Use feature flags. One of the best ways I have seen to control the rollout of a new feature is to develop and deploy it behind a feature flag. This concept is easy to do in Bubble with conditionals on elements and Only when conditions on workflows. So, for example, if a new feature is accessed via a button on a page, you could put a condition on the button to make it visible only when a user has a particular value in a field on their user record. Then, when you deploy the feature to production, you can give certain users access to the feature by selectively adding the appropriate value to their user record. Oh, and if you aren’t familiar with the term dogfooding, check it out because a feature flag combined with that concept is a fantastic way to make sure a new feature is truly ready to go before you make it available to everyone.

Anyway, those are my thoughts on the subject, and I hope they are helpful. Maybe others will come along and share their thoughts, too, because like I said, there really isn’t a single or right answer on this one.

Best…
Mike

2 Likes
3

@mikeloc Wow thanks a lot for the comprehensive answer and it makes a lot of sense!

I wasn’t even aware of feature flags or dogfooding and they seem like good strategies to use!

Thanks again for the effort put in your reply, it really goes a long way!

And yes I’d also like to hear what tips other bubblers have on the matter…

1 Like
4

Here in 2020 - 3 years after this question was asked - I am very curious to hear from the community about advancements/best practices there may be in conducting feature rollouts in production apps.

I have a few specific questions:

  1. Say I have built a new feature and have rolled it out to a subset of users by hiding it behind a feature flag. Once the feature has been tested and ready for wide release, is it better to enable the feature flag for every user, or make the feature a default behavior. Said another way: if I have released 100 new features to my complete user base over the course of a year - should my application have 100 feature flags/checks against every user? Or should new features eventually be considered part of the core application that are usable without a feature check?
  2. Say I want to develop multiple features at a time. Rather than add a binary flag for each feature in the database, is it better to create a list of Feature Options that can be subtracted/added to a user at any given time?
  3. What are good ways of measuring the impact of a feature release. I know that Bubble has the Professional plan only Google Optimize integration but are there other tools out there you like to use to measure feature adoption/reception? I see there is a Bubble created Optimizely plugin but I can’t seem to find documentation on how it works or if it ties in with Optimizely’s Feature Rollout functionality (that would be cool!).
  4. What is the best way to go about removing old features? Are there any clever techniques or rules one goes about here or does this usually just boil down to the classic delete it. What does general housekeeping with old features look like?
5

Reactivating this topic from 2020 to see if anybody has more good practices to share about feature flags and dogfooding. I want to control the rollout of some features and have basically the same questions @zelus_pudding had 3 years ago, especially #1 and #2.

1 Like
6

I think it’s still largely an unsolved problem. Google Optimize has been shutdown, so arguably the best plugin for rolling out feature flags (what had been an official bubble plugin) no longer works.

If someone has cracked this nut in a way that’s flexible / actually reports the results of A/B tests, I’d love to hear details. If not, I’ll start working on a plugin to address this in 2ish months.

2 Likes
7

For the task I’m currently working on, I just need to control the feature rollout for beta testing, so I’m not worrying too much about scalability or analytics at this point. We select our beta testers manually, based on our relationship and how keen they are to test features that aren’t stable yet.

I decided to use an approach similar to what Bubble uses for its beta feature toggling:

image
image858Ă—626 41.9 KB

Apparently, Bubble doesn’t flag users with a boolean value (yes/no) as beta testers, but instead adds a list of beta features the user has opted in.

So I created an option set called “betaFeature” where I can create a new option for each feature I want to deploy for the beta testers. I also created a new field called “betaFeatureList” in the user data type, where I can add the features the user has opted in.

A few advantages I see of designing the beta feature system this way:

  1. You can allow users to test multiple beta features at a time without losing control of who is testing what;
  2. It gives more flexibility for users to decide what they want to test. You can create a page where they can tick the features to test and if anything stops working, they can easily turn features off on their side.
  3. Using the app search tool in the editor, it’s easy to find all the places where you set conditionals for a specific beta feature. Select “uses option”, choose the “betaFeature” option set and then select one of the options to narrow down to a feature. IMO, this is the best advantage of option sets for this use case, other data sources don’t offer the same level of filters, which can easily generate a maintainability nightmare.

image

I use ClickUp to manage my development tasks, so I added a new status called “beta testing”, which will help me keep these tasks on my radar. When a feature is already stable, I can use the app search tool, remove all the conditionals, make the task available to all users and change my task to a final status like “released”.