Code, Design, and Growth at SeatGeek

Jobs at SeatGeek

We are growing fast, and have lots of open positions!

Explore Career Opportunities at SeatGeek

Keeping Track of Build Artifacts

easily track build artifacts from your continuous integration setup

In the process of building our Android application, we felt a need to send out test builds. As the Android ecosystem is much larger in terms of number of devices and versions of the operating system in use, we needed an easy way to distribute these builds. Internal android users and external testers needed the latest version of the android app to report bugs, suggest features, and suss out minor issues with the app.

What we did for the first few weeks was the following:

  • Have a developer make a build
  • Send out the build via email to interested users
  • Have them further disseminate that build to other testers

This didn’t work as by the time the last people retrieved a build, existing issues were already fixed in subsequent builds. It became the testing version of the telephone game.

We already had continuous integration for the Android app on TravisCI - if you haven’t used Travis and don’t yet have testing infrastructure, we wholeheartedly recommend it - and we wanted to hook into this process. Our testers should be able to view any build, filter by branch, and tell us exactly the build number they tested. This should all be automatic, with no other intervention from the developers.

In our case, we run the unit tests for the SeatGeek Android App on Travis. Travis notifies our hipchat account and uploads the latest APK to S3, at which point anyone in our dev room can download the app to test.

For non-developers - and testers not in our company - this doesn’t work as well. The dev room is a private room, and while we could rebroadcast the message, that doesn’t solve the issue of simplifying tests of multiple versions.

Thus, we built build-artifacts. build-artifacts is an app built with the Slim PHP framework - similar to Sinatra in Ruby or Flask in python - that can be deployed to Heroku or on your own infrastructure. The build-artifacts admin recieves a post-deploy webhook from travis, signaling that a build has completed - successfully or otherwise. We then store this data in ElasticSearch and show a small admin panel with the latest 10 builds, regardless of branch. We also showcase the latest stable release, so that our internal users can see the latest and greatest without mucking around with their systems.

Here’s a screenshot from our own instance of Android app build-artifacts running on Heroku:

SeatGeek Android app build-artifacts on Heroku

The app has worked well in our internal testing, and has definitely simplified our application testing. Download build-artifacts and give us some feedback. Pull requests welcome!

Comments