Developing an app is exciting and fun. You get to let your creative juices flow and create something people will want to use. Your days/nights/weekends are spent working away in your dev(elopment) environment, creating new features, running tests, finding bugs, finding design gaps, etc, etc. Create, test, fix – rinse & repeat. Life is good in your little dev environment…
Then you get to a point where you’re ready for people to start using your app so you release it to your prod(uction) environment. This might be for your MVP, perhaps a beta release or even your first full-production (“live”) release. Pretty cool. Users are creating accounts, they’re doing whatever it is your app allows them to do. Life is good in your prod environment…
And then you start getting feedback from Users for feature enhancements. Or you finally have time to develop that new feature that’s been sitting in your backlog. Either way – you need to get your head back down into developing in the dev environment.
It’s at that point you realize you need a new data field – and you realize another data field should actually be a different data type (i.e. character/text instead of boolean). So you make the changes in your dev environment, run some tests…And life is good…
That is until you push the release into your prod environment and Users start complaining that the updated feature doesn’t function as expected. Since you added a new data field, for the existing Users, the new field is empty (uh-oh!). And the other field where you changed the data type; well it behaves like a new data field too, so it’s also empty (ugh!). How did you get here and what can you do to fix it?
One way to prevent these issues escaping into your production environment is to execute test cases that not only test the creation of new users (“dummy” accounts) in your dev environment but also simulate “legacy” dummy accounts. This way you can exercise different test paths for both new and old users which should expose any data gaps.
Once you’ve completed testing, you should have a good grasp of the impact the new and updated data fields will have to your Users. With this knowledge, here are two simple examples of use cases you need to address once you pushed your app into the prod environment.
Case 1 – New Data Field
For the new data field, once your app is prod, you’ll need to go and pre-seed (or initialize) the data field with the correct data (i.e. a “yes” or “no”. With bubble, you can initialize the data (if the use-case warrants it) while in the dev environment so everything is pre-populated as you push the app into prod. If it doesn’t make sense for the data field to be pre-populated, you’ll need to go into each of your User’s data records and update the field. While a bit painful to make updates, the silver lining is Users may not notice any impact in the app since it’s a new data field which they probably haven’t used yet. Regardless, you want to make the data updates immediately after moving your app to prod so you minimize any User impact.
Case 2 – Modified Data Type
If the data field is modified (i.e. character/text from a boolean “yes” or “no”), there’s a bit more User impact since the data field is already being used by them. With bubble, changing a data type is treated effectively as a new data field so the old data field is “gone”, replaced with the new data field. As such, before you push the app into prod, you want to capture the value of the old data field for each User. Then when the new version of the app is in prod, you will know the value from the old data field to put in the data field with modified data type. If you don’t have the old data, you may get some unpleasant User feedback.
Thinking thru your data as part of the design of your app is very important. As you can see from this article, adding or modifying data fields after you have Users on the app can be a challenge. While you won’t know everything up front in the design of your app, spending time to think thru your data structures will pay dividends down the road.
