Ole Michaelis: Automated deployments with robots

Orde Saunders' avatarPublished: by Orde Saunders

Ole Michaelis (@CodeStars) was talking about automated deployments at Scotland.js, these are my notes from his talk.


Deployment is putting your code into production, there are different approaches.

  • Copy your code onto the server - rsync, SVN up, ftp, bittorrent

Deploy often. Deploy early. It should be part of your development cycle, preferably continuous deployment (the next step after continuous integration).

  • Tests
  • More tests
  • Even more tests

(or just trust your co-workers!)

  • Unit tests
  • Integration tests
  • Functional tests
  • Acceptance testing

What should continuous delivery look like

  1. Commit (or push)
  2. Test
  3. Deploy
  4. Test (again in live)


Hubot is a robot that joins your company's chat channel. Created by GitHub, written in CoffeeScript, runs on Node and Reddis. Has lots of chat adaptors, two built in and a number of plugins. 14 inbuilt scripts and a large number of third party scripts.

To extend Hubot there are some interfaces you can use:

  • Commands directed to him
  • React to any word spoken
  • HTTP requests
  • Event system

Example of Hubot in action

  • Code on GitHub
  • Apps on PAS
  • Two developers
  • Chat system
  • Didn't have enough tests to do CD.

Hooked up Hubot to the PAS platform to deploy the apps. When ready to deploy then manually instructed Hubot to deploy via chat. Could be linked to CI system so that when it passes then it can use Hubot trigger an event which then does the deployment.

Better than push deployment is pull deployment. If a server does not get the push at the time it is sent then it is left out. Better is the server checks for new updates and then pulls the new package. Distributed systems (such as BitTorrent) can reduce the load on the deployment master.

Comments, suggestions, corrections? Contact me via this website