Continuous integration / continuous delivery
Not every update can be pretty GIFs!
So, there's a lot of moving pieces that go into the itch.io application, and some of these need to be built for multiple platforms and multiple architectures (32-bit and 64-bit). Some of these can be cross-compiled (for example, by using `mingw-w64` on Linux to produce Windows binaries), but some steps of the processes (code signing on Windows & OSX for example, or generating Windows installers using Squirrel.Windows) can only be run under their native OSes.
When you put all the steps together, it can be a little time-consuming to release something by hand, and enough devices are involved that you can't just "throw a script together and hope for the best". That's where Continuous Integration / Continuous Delivery comes in: you use a server to orchestrate the work whenever a change is made to software. That server is responsible for tasks like:
- Running a bunch of tests
- Building various versions of an app
- Uploading builds to some cloud storage (like Amazon S3 or Google Cloud Storage)
- Updating manifests that let various programs know if there's an update available
- Notifying the devs if something went wrong, etc.
For open-source projects, we (and the rest of the world) use the fantastic Travis-CI: https://travis-ci.org/itchio/rsync-go — it's free, it's fast, and can run pretty much whatever under Linux & OSX.
However, some parts of our infrastructure are closed and/or require more resources than travis gives away. For that, we have a Jenkins instance. Jenkins has been around forever, and has pretty much all the peculiars you'd expect from a piece of Java software, so configuring it is not the best job in the world.
Thankfully, there are tools that turn human-readable YAML markup into the mess of XML that Jenkins uses as configuration. The idea being that you can then store all of your configuration into a single, human-readable version-controlled repository, and use that tool to let Jenkins know, via its API, what it should do.
One existing tool is jenkins-job-builder: https://github.com/openstack-infra/jenkins-job-bui... — but I wasn't fond of its template system, nor its error reporting, so I'm writing a cleanroom implementation of a very similar tool, but in ruby:
Its purpose is exactly the same, and I'm currently making sure cigales passes the same tests jenkins-job-builder uses (to generate XML from YAML correctly), the main difference is how the macro system works. (Basically, `:macro` defines, and `.macro` uses, see this example)
It's open-source, just like most of the client infrastructure, so if you want to help, ping me! I'm hoping to be done with it real soon, because I can't wait to get back to developing the actual client and associated tools.