Developing some piece of software on your own is usually simple in terms of infrastructure as you can do pretty much everything you want, including using all kind of tools and workflows that nobody else would need to understand or appreciate. This is of course another story when several people are involved, and usually working at the same time on the same project. Then you need a Master Plan (as illustrated)!
In the case of Naked on Pluto, we need to deal with the following constraints:
- each of us need to work on the game and experiment with the code, often at the same time
- the game requires a PLT Scheme/Racket server proxied with an Apache HTTP server
- It should run live to fetch data from the FB API respecting the same-origin policy
Of course we could all have a local server on our own machine with all the required applications running and using cached or fake data from FB. The main issue with that is obviously not being able to take a peak on what the other is playing with, not to mention the impossibility to invite someone to try some experimental feature with its own set of FB data.
To solve these annoyances, we have a quite simple setup that allow us to work on our stuff live and commit to a production server when we’re happy with the result. On the Debian server, we run in fact 4 games simultaneously, 3 for our own dev experiments and a production one. They are all independent from each other and rely on their own git clone repositories of the game-client and the game-server. The scheme servers are all running on different port listening on the local interface only and Apache proxies allows us to connect to them via different sub-domains. This way we can all experiment on our own and when we’re happy with the result we can push to gitorious and thanks to a small cron job the production server is regularly pulling from this “main” repository the latest in the master branch. The only downside of the setup is the need to have four different FB API keys and registered applications, one for each sub-domains the game is running from.
With this setup, working remotely is then possible using personal preferences: writing from inside a screen, using emacs with TRAMP, mounting an sshfs directory, etc.
More information on the provided DIY blueprint ;)
Fun, joy, happiness!
Tags: apache, API, collaboration, git, infrastructure, proxy, same origin policy, scheme, server