Is there a way to allow a new update to a percentage of my users?

[JeanLebrument]

Hello,

I wonder if there is a feature that permits to progressively release a new version of my application in production? For example with a first step with 20% of my users and then 100%?

Best,
Jean

[lostintangent]

This is high up on our todo list, but it isn't currently possible unfortunately :( Would this be a compelling feature for you? Any feedback here would help us prioritize the work :D

[JeanLebrument]

Yes definitely! I can do the trick using my back-end: Segment users in two
groups. The first one is composed of 20% of my users and the app is updated
each time a new release is available. For the other group, the app will
rely on a boolean value set from the backend to do the update or not.

Could be an option but definitely less convenient than handling this
feature from your side!

On Tue, Feb 2, 2016 at 10:45 PM Jonathan Carter notifications@github.com
wrote:

This is high up on our todo list, but it isn't currently possible
unfortunately :( Would this be a compelling feature for you? Any feedback
here would help us prioritize the work :D

—
Reply to this email directly or view it on GitHub
#174 (comment)
.

[lostintangent]

Hey @JeanLebrument! So we're beginning to take a look at this and I wanted to get your thoughts on a few things. We were thinking about solving this by adding a new parameter to the release command that lets you specify the percentage of users you want to be eligible for getting it. Then we would add a new command that lets you increase the fraction over time. Does that reflect your thinking? Would you want to be able to decrease the rollout fraction for any reason? Additionally, would you want to be able to release new updates while there was a rollout currently active (not 100% distribution), or would it make sense to restrict releases until an rollout has "completed"?

Your previous comment also seemed to indicate that you were thinking about the rollout segmentation spanning multiple releases as opposed to an individual release. Is that accurate? We were thinking that an individual release could be released as a staged rollout, and once completed, the next release could choose to be a rollout as well, but you would have to specify that you wanted this behavior when releasing it.

Any thoughts here would be greatly appreciated, since I want to make sure we're accounting for your requirements. Thanks!

[JeanLebrument]

Hey @lostintangent

Thanks for your interest on this ticket!
I guess for now, a simple solution should do the job. The two command lines you proposed seem cover the need.

• Would you want to be able to decrease the rollout fraction for any reason?

I don't think I would need such a feature. If a rolled out version is buggy, I would revert to the last stable version until a new version fixes the bug rather than decrease the number of users on the bugged version.

• Additionally, would you want to be able to release new updates while there was a rollout currently active (not 100% distribution), or would it make sense to restrict releases until an rollout has "completed"?

It makes more sense to me to restrict releases until a rollout has "completed". Having too many fragmented versions over the users could be really painful to manage.

• Your previous comment also seemed to indicate that you were thinking about the rollout segmentation spanning multiple releases as opposed to an individual release. Is that accurate?

Not really. Exemple of what I was thinking: Let's assume that I have a version 1.0.0 released to all my users, then I worked on a new version (let's call it 1.1.0) with fixes and a couple a new features. I want to test this new version on 10% of my users just to sure that it's stable. If so, I will progressively increase the percentage until 100%. Otherwise I will revert all the users to the version 1.0.0 waiting the new version to be fixed.

Feel free if you need further informations.

[lostintangent]

OK cool, thanks so much for confirming this. We should have a PR out for this pretty soon, and I'll pin you as an FYI.

[JeanLebrument]

I'm glad that it helped and good job for the tool!

On Mon, Feb 29, 2016 at 5:08 PM Jonathan Carter notifications@github.com
wrote:
OK cool, thanks so much for confirming this. We should have a PR out for this
pretty soon, and I'll pin you as an FYI.

—
Reply to this email directly or view it on GitHub .

[mvayngrib]

it would be good to have fine control in addition to percentages. Off the top of my head, in the app you can set an id for the installation:

CodePush.setID('..some stable device identifier..')

then on the dev end something like:

code-push ls-devices <appName> ...

and then during the push, you could push updates to specific users or groups of users by ID.

[lostintangent]

@mvayngrib #190 is also tracking the ability to target releases at specific people and/or groups, which is definitely something we want to do. I was just using this issue to discuss the percentage based rollout.

I really like your proposal! I'll let you know as soon as we start thinking about this feature.

[lostintangent]

This has been addressed and is now live! You need to upgrade your CLI to the v1.8.0-beta release and your React Native CodePush plugin to the v1.9.0-beta release in order to take advantage of it. Both of those include numerous other improvements, so hopefully it will be worth it :)

Check it out and let us know if you have any feedback. Thanks!