[Docs] [best practices] 3rd build type for Android

[vonovak]

Hi! I'd like to discuss this: the guide on multi deployment testing uses 2 build configs for android (release and debug) while it uses 3 for iOS (debug, stage, production).

I believe it would be beneficial to add 3rd build config for Android as the recommended approach.

• debug - development; code push is not being used here because it makes no sense
• stage - stable version for testing. Changes are pushed here from the debug version
• production - what customers run. Changes propagated form staging.

Opinions?

related: #439

[vonovak]

I have solved this to my satisfaction by adding a third build type, as described above. This however, also required the ability to configure devEnabled for the build type which is currently not possible. Here's a PR in RN core that would allow it, comment it if you find it handy.

[vonovak]

@Silhouettes sorry to bother, do you have an opinion on this? Thanks

[sergey-akhalkov]

@vonovak - hi! The fact, that JS bundle is still loaded via React Native packager (due to jsCodeLocation variable is configured to use React Native packager for each app restart in debug mode) after CodePush updates were installed, is confusing: there are two questions about testing CodePush updates in Debug mode: #672 and microsoft/code-push#364.
That is why I also believe that Debug (implementation/bugs fixing without using CodePush) -> Staging (Testing CodePush updates) -> Production (promote tested CodePush updates to production) workflow is convenient and also suppose that having 3 build configs is seems to be very handy. And @goldylucks is probably right in #667 that docs should be updated to let users know about "confusing fact" and better workflow.

[goldylucks]

My android workflow ATM, (no codepush) is:

1. Develop and test locally (usually on emulator)
2. upload new apk to alpha, where I'm the only tester (and maybe some close users)
3. if all works, promoting alpha to beta (usually running open beta)
4. if all works, promoting to production

with codepush there should b minimal app version changes, so I think the workflow would b:

1. develop and test locally
2. code-pushify changes to alpha
3. code-pushify changes to beta
4. code-pushify changes to production

Assuming iStore also has easy alpha, beta, and production management for an app, I'll do the same workflow there.

@sergey-akhalkov what do u think?

@vonovak what is your "staging" ?
is that another app that's unlisted on the stores?
or a beta/alpha version of the same app?
do u have your apps on both iStore and google store?

[sergey-akhalkov]

@goldylucks, provided workflow looks good, but I've said above:

I also believe that Debug (implementation/bugs fixing without using CodePush) -> Staging (Testing CodePush updates) -> Production (promote tested CodePush updates to production) workflow is convenient

By default CodePush has Staging and Production deployments, and the new one could be added manually by executing code-push deployment add <appName> <deploymentName> command.
I think the issue is that current version of docs does not pay attention on the fact, that CodePush updates should not be tested in Debug mode due to React Native packager is always used in Debug mode to load js bundle.

[sergey-akhalkov]

docs does not pay attention on the fact, that CodePush updates should not be tested in Debug mode due to React Native packager is always used in Debug mode to load js bundle.

So I've also created #682 ([docs] CodePush updates should be tested in Release mode only)

[vonovak]

@goldylucks release is what the app users are running, staging is what we use for testing internally. New features of the app are first code-pushified to staging where they can be tested. Once done, they are moved to production using code push promote