Tools & Methods:

  • Git: Source Code Management (and improved development workflow).
  • Uptime Robot: Realtime website status notification.
  • LogMeIn and iTeleport: Remote computer management.
  • OAuth: Authentication method to protect your API.

General Insights:
TILO has been in development for almost a year and has been in planning for almost 2 years. Although TILO is now quite an elegant efficient solution it has gone through a number of iterations, and some of those were not very pretty and were awkward to work with.

Despite the additional year of planning before development began we didn’t fully understand how it would be embraced and used until we had a version installed. We learnt more in the first 2 weeks that TILO was installed than the 3 months of development that preceded it.

Our first mistake was because we had such ambitious plans for TILO we tried to implement them all straight away. We also had a very enthusiastic client that was keen to suggest new functionality which we enthusiastically added to our feature request list. We quickly ended up with a product that was feature rich but bloated as a result.

At one point development ground to a complete halt, we were pushing new features that could couldn’t be supported by the foundation we’d hastily put in place with no clear purpose, as a result functionality was inter locked and subtle changes had an impact in multiple locations. Added to that our live and development platforms were too closely linked, a bug in the code on our development platform could leak over to the live. It was around this time we knew we needed to slow down and take a more measured long term approach to our code.

This sounds like a disaster but it wasn’t actually that bad, we just knew we couldn’t continue with our current approach. We had all the features we wanted, it just wasn’t held together very well. We needed a new ethos to adding functionality to TILO. We decided that:

TILO should only manage basic CMS functionality. All additional functionality should be added as stand alone modules that interact with TILO through a simple API.

We started using OAuth and exposed a simple API that could be used to command TILO to:

  1.  Trigger templates
  2.  Interact with the database

With this simple approach we realised that not only could we re-write our bloated CMS as independent third party modules, but other developers/artists could contribute their own modules and tools. As an added bonus, by re-building our CMS using the API we were effectively testing it for other developers and providing working examples. This got our development team quite excited, bless them, they don’t get out much.

Whilst we were reviewing our processes and workflow we also implemented:

Git Integrated Workflow:
Previously Git had only been used for version control. To speed up our workflow and improve stability we added Git to our server and used it with scripts to stop/update and restart our applications as updates were pushed to it. This was integrated with test scripts so updates would only be applied if all tests were passed. This removed human error from the process and the number of bugs reported by the client dropped significantly.

Independent application instances:
Initially we had a single instance of TILO running that was designed to handle all clients. Big mistake. It meant that to update one client we had to update them all. Using Git we set up a script for each client that would checkout a specific version of TILO, test it, and then upload it to it’s own instance on the server. The server is now running multiple versions of TILO and also has an instance used just for testing, they each hang off their own subdomain so can be individually addressed.

TILO is now running very well and our development team get a lot more sleep as a result.