Feature request: override CodePushDeploymentKey for a deployment

[talkol]

As far as I understand, when a new deployment is created via the CLI, a new random key is generated.

It will be great if we can override the deployment key for a specific deployment manually.

Consider the following use-case (that actually happened to us):

1. Code-push setup in the project and key pair generated and put into Info.plist
2. App was uploaded to the app store
3. Since a new code-push update was accidentally pushed into this deployment before Apple review, the deployment was deleted to avoid having the reviewer receive an update when launching
4. The app passed review and went live
5. Due to some code changes, we wanted to publish a new code-push update
6. The deployment was re-created but a new key was generated which is different from the key in the live app rendering this app un-updatable

TLDR: There are some cases where users will have live apps locked to specific deployment keys. For various reasons, these deployments could be lost in the code-push server and need to be able to be reconstructed without changing the key.

[lostintangent]

Hey @talkol! Apologies for this issue! Yeah I totally agree that this isn't an ideal scenario as it stands. Just thinking about your scenario a little bit, I'd love to pose a few potential options and see what you think. Some of these might be horrible, but for the sake of conversation, I just want to toss things on the wall :)

1. We could enable "clearing" a deployment (e.g. code-push deployment clear [APP_NAME] [DEPLOYMENT_NAME]), so that the key remains the same, but the history of releases are completely cleared. This would have the same effect of deleting it and re-creating a new one that used the same key. This could potentially also have the benefit of "cleaning" up a deployment that was used for testing/development that you now want to re-purpose/etc. but it's questionable whether in that case you couldn't just delete/re-create the deployment since during development it isn't so valuable to retain the same key.
2. We could allow you to actually delete a release from a deployment history. Right now, the deployment history is immutable, but we could certainly discuss changing this. That would have allowed you to remove the release you didn't want to be installed without needing to delete the deployment entirely. This would effectively only be valuable if you had additional releases on the same deployment that you didn't want to completely clear using Implementation first pass #1. Additionally, this could potentially be valuable if you accidentally released an update that you don't want to rollback because it would stay in your history, and you just want it completely gone.
3. We could allow you to "disable" a release (or deployment) so that even though it's part of the deployment history, it won't be retrievable by any clients. This would have allowed you to retain the existing deployment and release, while having the benefit of simply hiding it until you want it to be available.
4. We could allow rollback to work on a deployment with only a single release. Right now, the rollback command rejects the scenario where you try to rollback a deployment that only has a single release. This is because the deployment history is immutable, and therefore, a rollback operation simply makes a new release whose contents/metadata are equal to the rollback target. When there isn't a rollback target, there wouldn't be anything to release. I'd hesitate to overload the rollback command to effectively support deleting a release if there wasn't a previous, as opposed to simply enabling you to delete a release via option Refactor plugin config, and change example so it can download updates #2
5. We could support your suggestion of allowing a specific key value to be provided to the code-push deployment add command.
6. Others?

In general, I definitely want to support the scenario you ran into, but I'm wondering if there is a way to do it that is a little more "clean" that simply allowing the creation of a new deployment with a specific key. I'm not personally in love with #1, #2 or #4, because I feel like changing the immutability invariant of a deployment's history will have downstream effects, and I like how simple/intuitive rollback currently is, so I'd hate to overload it to also support deleting a release in certain scenarios.

I think #3 could make a lot of sense, since the deployment history itself is still immutable, rollback remains the same, and you don't need to worry about mangling keys. It simply solves the problem of turning the deployment on or off with the intent of "hiding" the release from people during a timespan. This could also be used for other scenarios besides the one you reported, so it feels like a simple and natural addition to our existing workflow options.

Thoughts? Thanks so much for the feedback?

Additionally, in the meantime, we could fix up your deployment to have the old key, that way your app isn't orphaned in the wild. Send me an e-mail at joncart@microsoft.com and we can take care of it :)

[artald]

I have to agree with @talkol on this.
When a live app is bound to a specific deployment key, it makes sense that this key will remain valid even when a certain release\deployment is removed. That's the whole point of pushing code remotely, so you wouldn't need to update the app itself...

Personally i'm leaning towards the second option of completely deleting a release from the deployment history. Alternatively, the third option of disabling a release would also work, as long as rollbacks will "know" to skip disabled releases.

[lostintangent]

@artald 100% agreed. I want to remove the need to ever delete a deployment that is actually in use, and therefore, figuring out the core needs here would be awesome, so we can bake in the necessary support, without needing to resort to deleting/recreating a deployment, and trying to restore the key.

[lostintangent]

Hey @talkol! Have you had a chance to think about this?

[zoontek]

I've just met a similar problem.

My app was already uploaded to the Play store (in beta program).
Since it was the first time I perform an update using code-push, I ignore about the different possible deployments (Production, Staging and more). My release was broken (no images), and since it was my first one, I couldn't rollback.
I delete the deployment channel and recreate them (with a new key).

So I think a "clearing deployments" could be awesome.

[lostintangent]

Hey! So just a quick update: we're working on implementing both the ability to clear a deployment history, as well as the ability to "disable" an individual release within the history. That way, you'll have a lot more flexibility over your deployments than you currently do.

Our hope is to have these both out within the next week, along with some other new features (e.g. rolling out releasing to a percentage of users), so stay tuned and I'll update this issue as we send out the PRs.

[lostintangent]

We just shipped the code-push deployment clear command as part of the 1.8.0 release of the CLI to address this request. We're also going to pursue disabling individual releases, but we'll track that as a separate issue. Thanks for the feedback everyone!