There were (for us) many firsts with the release of Starry Night Pro Plus 7. Exoplanets, data streaming, in-application updates, automatic crash reports - to name just a few. The scope of these new facilities and modernization of the old ones required tons of development time on the app itself. In addition, a lot of development had to be done on our servers too, a topic of a future article.

There is, however, one other area which has required many hours of development and use of a large number of technologies, most of them necessary to automate the process. This component is now integral to the lifecycle of SN7 and any future versions of our desktop applications. It assures that problems are caught early and that updates are tested before everyone gets them. I am talking about our Starry Night Beta program.

Mentioning beta testing evokes notions of release candidates, fixed release schedules and long delays between changes in the beta code and their eventual release to the public. We, of course, do our best to adhere to the wisdom of desktop beta testing. However, we also wanted Starry Night Beta to be more agile, and, above all, always alive.

Among other things, with the new automatic crash reporting and streamlined workflow of dealing with bug reports and user submitted support tickets, we wanted SN7 development to be as responsive to our users as we can make it. We scrutinize every crash report and investigate every bug report. We try and catch problems early. And we want to get relevant improvements and fixes into the software as soon as possible. This is what drove our implementation of in-app updates. And this is what drives our efforts in keeping Starry Night Beta going, even after SN7 has been released - because updates need testing too!

There are many arms to the beta (sometimes also referred to as "nightly") builds of SN7 and the systems used to get changes as quickly as possible into the hands of our testers. Here they are in their raw, technical jargon. All of the following tasks are fully automated, set in a sequence, and alert the developers of any problems encountered along the way.

Mac: checkout from the relevant branch of SN7 git repository

Windows: checkout from the relevant branch of SN7 git repository

Mac: build SN7

Mac: checkout from the relevant branch of Sky Data git repository

Mac: pool all the data for Pro Plus into the new Sky Data folder

Mac: add in the Manual and User guide to the final application

Mac: checkout from the relevant branch of AllSkyImage git repository

Mac: add all the AllSkyImage data that needs to be bundled into Pro Plus final app

Mac: build the latest Mac telescope plugin and add it to the application

Mac: codesign the final application bundle (to satisfy Gatekeeper)

Mac: store the freshly built app until relevant build number in our application storage

Mac: construct a pkg installer of the application

Mac: build a DMG disk image for the pkg installer to make the installation clearer and easier

Fire up a very large AWS EC2 instance that is used to quickly compress Windows installation data

Mac: rsync final application to the EC2 instance

Mac: create a drag-install DMG on Linux using genisoimage and libdmg-hfsplus

Mac: push built dmg to S3 for (full) updates

Mac: push the new build number to the relevant branch of SN7 git repository

Mac: package and push the new symbols file of our application to HockeyApp - the service we use to receive crash reports

Mac: read the relevant build release notes, if any, from our SN7 git repository, otherwise use current date stamp as a comment for the beta release

Mac: copy the built pkg-based dmg installer to S3 for distribution (this is currently the slowest part of the process which is why it is last)

Finally, on the distribution chain, we keep things separate between public releases and Starry Night Beta. Applications built for public release are essentially different builds (which is why beta versions and release versions will never again have the same build numbers). Beta builds only get beta updates. The same rule applies for public releases. On Mac, our appcast server reads different entries from our release database (to which information is added during the above build steps). On Windows we keep separate wyserver.wys and wyBuild projects - one for public releases and one for beta.

And this is just the nightly automated script for a single application (Pro Plus 7)! There is still a lot to be done to improve this system, parallelize some processes and implement failover solutions for others. We are currently using Parallels VM in order to easily script everything directly from one source. However, a Parallels VM could be replaced with another EC2 (Windows) instance. We want to keep the nightly builds no matter what and to make them faster and more robust! Even beta needs testing and development (a beta for Starry Night Beta?).