The current build and deploy process for Ananias takes a lot of time and requires lots of focus and bandwidth. Everything is done manually (and is thus prone to errors). Most of times I just can’t afford to release for all platforms, and I forget to announce thru all channels.
The cocoon.io parts are a bit cumbersome since they don’t have a CLI and it requires some back and forth, while also adding a dependency to an online service (for how long is it going to work?) I’m going to experiment with some native crosswalk builds to see if that step can be saved.
But probably what takes more time is the manual process to be done for each different storefront via its own web interface. Each one requires different info, and all uploads have to be started and monitored manually. It’s pretty uncommon for a store to supply a command line tool.
May be I should automatize parts of this? Someday I may do that, in any case it’d simplify packaging but wouldn’t make distribution any easier.
This is the current process executed for each new release of Ananias:
- Mark the new version in the source code (client and server)
- Generate a new JS bundle using browserify
- Upload new build to web (ananiasgame.com/play) (About 15MB) (Only Standard edition)
- Deploy new server version and restart (About 1MB) (including executing migration database scripts)
- Use nwbuild to generate the executable packages for Windows, Mac and Linux
- Rename the directories and zip them
- Upload to itch.io via web interface (About 200MB )
- Zip web directory
- Update config on cocoon.io for next version
- Upload web directory to cocoon.io (About 15MB)
- Hit the build button on cocoon.io, wait for build to finish
- Download APK packages from cocoon.io (About 150 MB)
- Unzip package, copy release APKs (one per architecture, x86+arm7) to APK directory
- Run script to sign and align APKs
- Sign in to google play developers console
- Upload both APK (About 100 MB)
- Build change log from git commit messages
- Summarize change log for Google Play
- Upload both APKs to Amazon via web interface (About 100MB)
- Upload to indiegamestand via web interface (About 200MB)
- Upload to gamejolt via web interface (About 200MB) (Only Standard Edition)
- Upload to IndieDB via web interface (About 200MB) (Only Standard Edition)
- Set cocoon.io for iOS builds
- Hit the build button, wait for build to finish
- Download xcarchive (About 50MB)
- Open xcarchive in xcode organizer
- Submit to App Store
- Wait for processing
- Go to iTunes Connect
- Go to Testflight / External Testing
- Select new build to test
- Wait for beta review
- Go back to Testflight / External Testing
- Set the new build as active.
The process should be executed twice, once for the Standard Edition and then again for the Fellowship edition.
THIS IS A LOT OF WORK. WHY CAN’T IT BE SIMPLER? This process takes out HOURS (Not exaggerating) of valuable and scarce development time for an Indie dev.
Why can’t I just simply update a single web endpoint, and have all the clients deal with the updating? they have to deal with it anyways, they just have to do it with their own, different store.
Also, the game is already multiplatform, if your platform has an HTML5 browser, like all modern platforms, you can play the game (Yes, you can even play the game on a PS4), then why go through all this?
I understand the advantages of having a downloaded app… people wants to feel they own the app, and they want to play their games while offline or in poor network conditions.
It would be awesome if the app could automatically check and download the updated scripts and required assets. This is not a new idea… some people has already tried but there are some obstacles:
- Both Play Store and the AppStore are not very clear about their support of this model. You may be risking your app being taken down for not complying with the terms of service. They are also not MEANT to work like this, so you are always fighting against their nature.
- For in-dev games, the player wouldn’t be notified a new version exists unless he runs the game or you implement some kind of push notifications.
- The system has to work perfectly, if it doesn’t then your players will be stuck with an old version, or will be unable to play offline, or will end up with a malfunctioning app.
- Another thing to consider is that this would prevent players from updating the web runtime in which the game runs, although I guess that may be fixed via a normal update.
- If the player uninstalls the app or erases its data cache, they will have to redownload all assets.
There is a cordova plugin (cordova-app-loader) which adds support for “hot updates”. It seems to work but has some issues (based on what people reports). I don’t know of any similar tool for node-webkit / NW.js, I guess it’d have to be done manually.
3 thoughts on “A better build and deploy process for hybrid apps?”
So, unless I missed a few details, and unless the disparate storefronts make up for publisher APIs anytime soon, you’re left with scripting as an automation alternative, right? Maybe next release can be intercepted by a JMeter recording proxy that would render a mostly usable script that you can later tailor to your needs. At least the publishing part can be automated like this, but given I haven’t tried JMeter scripts against, say Google Play, it’s still a long shot. Worth a try?
I just noticed Google Play has this https://developers.google.com/android-publisher/#publishing which is great.
For others, like itch.io, I guess I could try JMeter or even better, PhantomJS or similar… itch.io interface is clean and modern so I think it should work. IndieGameStand has a somewhat more complex uploading flow so not sure. I guess I shold give it a try, thanks! 🙂