Continuous deployment of 10101 app

[klochowicz]

With the recent usage of fastlane for building 10101-Test, we might be 90% of the way towards supplying continuous delivery of 10101 to the testers.

I'd like to share some thoughts around why I think this might be a good idea.

1. No need for releases
   • instead, concentrate our efforts forward, so that we shorten the cycle between having a bug and fixing it.
   • we are in closed beta, doing merge freezes and elaborate release process takes time that we don't need to commit; it's not essential for us.
   • Maximise the utility of testing (both for ourselves and for users)
     • If anyone finds and reports a bug that's not there anymore on master, it's wasted time
   • Ability to start/stop any experiments at a moment's notice.
     • Matters especially for the A/B testing and small experiments.
   • Distance to bisect the bug is smaller
     • In theory, we should get bug reports from vicinity of the change that introduced a bug, not at the interval of the next release (which could be 1-2 weeks).
     • quicker turnaround on the bug verification (ie. it's not present in production anymore.
2. ability to quickly deploy a fix in production for the users (== more happy users!)
3. Ability to quickly start / stop experiments (less constrained by the release window, which mandates sometimes waiting for yet another week).
   • technically, we could at least stop the experiments with Firebase (reading some value in the store), but it's not as clean as just deactivating piece of code and merging a PR.
4. Faster builds (tangentially, in order to achieve CD, we would ditch --dart-define flags, which means simplifying our Fastlane setup and making it slightly faster.
5. Shorter feature's time-to-market - deployment of a feature is instant, we would be able to better correlate features that make a difference to changes in metrics. Not to mention the dopamine rush of having it running live in the app the same day 😋

*** We could label something as a release post-factum, if we decide that the feature set is good enough for us.

• this is mostly for marketing purposes, and for celebrating our milestones (everything can stay the same in regards our milestones/epics)

Further reading/watching:

• https://www.belighted.com/blog/continuous-delivery-startups
• https://www.headway.io/events/continuous-discovery-delivery-making-impact-in-high-growth-startups

TL;DR: I believe that it's well worth the effort (with #1115 we're pretty much there, minus the backups, which should be addressed soon anyway).

[luckysori]

I like the idea of continuous deployment, but I'm not a fan of #1115. Why can't we continuously deploy both versions?

If we did this for both versions we could even have a develop branch CDed on our 10101-test app and main for the 10101 production app.

[bonomat]

Why can't we continuously deploy both versions?

One reason I see is that we do not have any guarantees that a newer app version is compatible with an older coordinator version.

That's also my strongest argument against having a regtest and a mainnet version in one app.

[klochowicz]

why wouldn't we continuously deploy coordinator too? That was implied by me. We don't have a requirement to support multiple versions at the same time.

[bonomat]

You mean continuously deploy the coordinator into production? I don't think this is a good idea given how fast things are breaking

[klochowicz]

note that with functionality like #1146 we should be able to catch most of these things (coordinator doesn't have frontend to worry about).
Of course, we could have an automated script that upon failure reapplies the old working state and alarms us about the regression to minimise downtime, or even a more elaborate pre-deployment test where it applies the DB and tries to load it up.

[klochowicz]

I like the idea of continuous deployment, but I'm not a fan of #1115. Why can't we continuously deploy both versions?

If we did this for both versions we could even have a develop branch CDed on our 10101-test app and main for the 10101 production app.

That's a valid point, we certainly could do that too!

My assumptions for deciding to do it instead were the following:

• we don't want to focus on things that don't bring us closer to the goals (maintaining 10101-test app is a constant source of pain, and gives us zero positive effect on KPIs
• all these CI minutes add up into cost too, and probably are not the best use of resources
• making it easier to test on mobile without uninstalling etc. would also save time.
• accidental complexity of 10101-test and 10101 slows us down and are not the typical way of deploying a project on iOS (fastlane supports it, but e.g. Firebase doesn't). we need to come up with workarounds for things that are a problem because of our config (eg. why notifications arrive at the wrong app).