search

Triple-T / gradle-play-publisher

GPP is Android's unofficial release automation Gradle Plugin. It can do anything from building, uploading, and then promoting your App Bundle or APK to publishing app listings and other metadata.
MIT License
4.13k stars 341 forks source link

Tracks and user fraction #977

Closed ArcherEmiya05 closed 3 years ago

ArcherEmiya05 commented 3 years ago

Good day, I wanted to know more about usage of GPP

  1. Does userFraction applies to all tracks even in internal track?
  2. What does the releaseStatus COMPLETED and IN_PROGRESS means?

Thank you

SUPERCILEX commented 3 years ago

https://github.com/Triple-T/gradle-play-publisher#common-configuration

  1. Yes
  2. In progress when you are rolling out a release, completed when done.
ArcherEmiya05 commented 3 years ago

Ohh okay so for internal track better to set userFraction to 1. Sorry what does rolling out means? Does it mean the track's userFraction is not yet in 100%? Does userFraction gradually increase automatically or is it manual?

SUPERCILEX commented 3 years ago

If you don't understand what a rollout is, don't mess around with the user fraction settings. It's for releasing a new version of your app to a small population of users and progressively rolling out the release (manually bumping the user fraction) to more users until you complete the release by completely replacing the old version. Basically just a way to avoid doomsday crashes.

ArcherEmiya05 commented 3 years ago

If you don't understand what a rollout is, don't mess around with the user fraction settings. It's for releasing a new version of your app to a small population of users and progressively rolling out the release (manually bumping the user fraction) to more users until you complete the release by completely replacing the old version. Basically just a way to avoid doomsday crashes.

Thanks so far I understand the purpose of user fraction but no idea whether it is automatically reaching all user little by little or the developer is the responsible for increasing it manually.

ReleaseStatus.[COMPLETED/DRAFT/HALTED/IN_PROGRESS] Regarding release statuses, are these correct?

COMPLETED the availability of the new version in store completely replaced the old version across all user. (update reached all users) DRAFT I assumed it is like when you manually publishing a new app or app update but not yet submitting it for rollout. HALTED I do not know this one, I assumed it is when the app update has been rejected? IN_PROGRESS the availability of new version in store does not yet reached all of its user. (progressively reaching all users)

SUPERCILEX commented 3 years ago

Yes, you have to manually choose when to increase the rollout percentage.

Draft: no idea why you'd use this. It means the app will show up in the release but not do anything.

Halted: you started a rollout and went "oh shit, we done goofed." No new users will be able to download the new release.

You got the other two. 👍

ArcherEmiya05 commented 3 years ago

Yes, you have to manually choose when to increase the rollout percentage.

Draft: no idea why you'd use this. It means the app will show up in the release but not do anything.

Halted: you started a rollout and went "oh shit, we done goofed." No new users will be able to download the new release.

You got the other two. 👍

Ohhh so Halted is when you decided to pull back and stop releasing the new version because it has a bomb on it. In console it is when you hit the pause track button.

Since internal track is for testing purposes within a selected group of people e.g. your co-worker or QA. It is safe to put 1 in userFraction right?

SUPERCILEX commented 3 years ago

userFraction doesn't do anything unless your release status is IN_PROGRESS. Just don't use it unless you're actually doing a rollout.

ArcherEmiya05 commented 3 years ago

userFraction doesn't do anything unless your release status is IN_PROGRESS. Just don't use it unless you're actually doing a rollout.

You mean only use it when doing a beta/production rollout? Does it also mean that we only get IN_PROGRESS status during beta/production rollout?

SUPERCILEX commented 3 years ago

Are you actually trying to release a new version of your app in stages? If not, don't use userFraction.

Staged rollouts can be used with any track (including internal). If you are doing a rollout, the release status must be IN_PROGRESS (otherwise it defaults to completed meaning the userFraction will be ignored).

ArcherEmiya05 commented 3 years ago

Are you actually trying to release a new version of your app in stages? If not, don't use userFraction.

Staged rollouts can be used with any track (including internal). If you are doing a rollout, the release status must be IN_PROGRESS (otherwise it defaults to completed meaning the userFraction will be ignored).

Yes I am releasing a new version.

The flow would be like internal track with a userFraction of 100% then after test, promote to production track by 10% progressively.

SUPERCILEX commented 3 years ago

Yup, sounds about right. Though again, a user fraction of 100% does nothing so you'd want to keep the release status as completed instead.

ArcherEmiya05 commented 3 years ago

Yup, sounds about right. Though again, a user fraction of 100% does nothing so you'd want to keep the release status as completed instead.

In the console I see no stage rollout option when trying to create new release in internal track. However stage rollout is available in production track where I can specify its percentage. So I assumed user fraction does not apply in internal track.

ArcherEmiya05 commented 3 years ago

Yup, sounds about right. Though again, a user fraction of 100% does nothing so you'd want to keep the release status as completed instead.

In the console I see no stage rollout option when trying to create new release in internal track. However stage rollout is available in production track where I can specify its percentage. So I assumed user fraction does not apply in internal track.

It also appears when releasing new app version under open testing track (beta)

SUPERCILEX commented 3 years ago

It might just be that they don't show it to you in the console (b/c doing a staged rollout for <10000 people is kinda pointless). If the API lets you though, GPP will be able to set the user fraction for the internal track.

ArcherEmiya05 commented 3 years ago

Yup, sounds about right. Though again, a user fraction of 100% does nothing so you'd want to keep the release status as completed instead.

In other words, instead of specifying userFraction value to 1 we could just specify the releaseStatus to ReleaseStatus.COMPLETED. But since by default releaseStatus value is completed we no longer need to add any additional options specially when what we want is to deliver update release on internal track that will be available on all tester immediately, just executing a gradlew task with :app:publishReleaseBundle already does that.

If we wanted to control userFraction for our stage rollout then we should also explicitly add the option releaseStatus and its value to ReleaseStatus.IN_PROGRESS so that the effect of userFraction option and its value will work.

SUPERCILEX commented 3 years ago

Yup, that was a perfect explanation!

ArcherEmiya05 commented 3 years ago

Yup, that was a perfect explanation!

At last!

One more thing before closing this.

  1. If you are previously doing a stage rollout but then you forgot to explicitly specify releaseStatus in IN_PROGRESS on your current/future release with GPP, will the previous stage rollout will mark automatically as completed?

  2. The first question seems doesn't make sense since the previous release should somewhat not related anymore with the current/future release if I am right so I will add this question as another scenario. Can we use just GPP to increase a userFraction not by releasing new version or promoting artifacts? If yes what if you forgot to explicitly specify releaseStatus in IN_PROGRESS when increasing it?

  3. When promoting an artifact from example, internal to production. What is the basis of GPP to execute this correctly? Is the versionCode supposedly the same in build.gradle file and what is in the internal track? I assumed promoting internal to production no longer needs to build another aab or apk since we already have it in app bundle explorer where all artifacts are listed.

SUPERCILEX commented 3 years ago

  1. Yup. Come to think of it, that's not the best of ideas. Maybe we can do something where if you've explicitly set the user fraction and not the release status, we'll implicitly set the release status to in progress for you. WDYT?

    The historical reason for not doing this is that the user fraction had to be set, so we provided a default at the DSL level (meaning we couldn't tell if you had set the user fraction or not). Now the default is provided in the business logic layer so the user fraction and release status will be null if you haven't configured them.

  2. Yes, that's part of the promotion task. You would make fromTrack and promoteTrack be the same value (a --update CLI flag exists that does this). As per 1, yeah, if you forget to set the release status we'll yeet you into completed. Again, probs not great.

  3. The promote task only needs a correct package name. Anything else app related is ignored, so you can have the version code be whatever you want. And right, we don't build the app again. It might help to just look at the API we're messing with yourself: https://developers.google.com/android-publisher/api-ref/rest/v3/edits.tracks#Release. There are multiple release objects, so one of them would be completed and another (with a higher version code) would be inProgress.

ArcherEmiya05 commented 3 years ago

Alright! Thanks a lot! Will close this now and will just ask more in the future.

SUPERCILEX commented 3 years ago

Lemme keep it open for a bit longer... I want to look into the auto in progress thing.

github-actions[bot] commented 3 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

SUPERCILEX commented 3 years ago

Whoops.

ArcherEmiya05 commented 2 years ago

Hi, just a follow up question regarding promotion of track. When promoting an internal track to production, does it always choose the most recent version in internal track? Thanks

SUPERCILEX commented 2 years ago

@ArcherEmiya05 yes, but there's an issue to support choosing specific version codes: #980.