Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
Admin (2 edits) (+2)

Continuous integration / continuous delivery

Not every update can be pretty GIFs!

So, there's a lot of moving pieces that go into the 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: — 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: — 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.