ClemensIs there a best practice for test-driving new updates before rolling them out to customers?
We are currently introducing wyUpdate for our customers to update an application in the field. We have two separate wyBuild projects for the two update channels "testing" and "prod". When we add an update to the "prod" channel, it would be great to test whether everything works fine before we are actually rolling it out to the customers.
I could imagine a strategy like this.1. Create a backup of the online update files on the server.2. Upload new update files to the server.3. (Quickly) test the update 4. If all goes well, we're done. If not, we can revert to the backup copy.
However, this seems like a bit of gambling because it will happen that some customers will have their machines looking for updates between steps 2 and 4.
We could of course change the URLs for the test but then we are not exactly testing the production scenario.
Any help would be appreciated.
Thanks,Clemens
JamesIf we could flag versions with -beta semantic versioning then we could have a config setting for the wyUpdate tool that will pick up these -beta version or not.
This would be a useful addition to target specific customers on different release channels.
watchmanmonitoringWe would also like an official way to do this.
The best way we have found so far is to have an intermediary server which proxies S3 and does a lookup to see if that client should get the new or old update and then pass the right one along. It could either choose based on the IP, the URL its checking, or a URL argument (we will prob go with a URL argument.)
There isn't currently a "best practice" for testing updates. It's entirely up to you. The easiest method is upload the update files (*.wyu) but not overwriting the *.wys file. Just use the -server commandline option to test the *.wys file locally: https://wyday.com/wybuild/help/wyupdate-commandline.php#server
This way "rolling out" your updates to everyone is as simple as replacing the *.wys file.
