Docker helps us deploy to Buddycloud’s testing and production environments. We use Docker to run Buddycloud’s hosted environment. And deploy after every commit to our testing and production Git branches.
Again and again.
Background: we’re holded up in the Austrian mountains working on the new Buddycloud hosting platform. We need to be able to reliably test and deploy code. What generally happens is that, unless servers are completely rebuilt between test or production, they slowly degrade over time. A new library here, a config change there. And soon your tests are no longer against a vanilla environment.
Also, we want to be testing on exactly the same environment that we are running in production.
What services should be run under docker and what are “core” services that other apps use?
We separate core services like databases, DNS and LDAP (for server authentication) from services that are updated and managed by Docker. These is is our plumbing - it’s just got to be there.
This has the knock on effect that when we do deployments to services that use a database: the deployed service or the application MUST take care of ensuring that the database is at the correct schema version.
This is a good thing: it keeps us honest about upgrades working smoothly. And catching failures before they hit production.
By default docker exposes no ports. We need to expose some ports to the outside world, and some ports to localhost so that processes can intercommunication. For example our Apache instances run a reverse proxy back to the buddycloud-http-api. The ports are exposed using the docker startup commands.
For example Apache uses
docker run -d --name=apache -h=si.buddycloud.com -P -p 80:80 -p 443:443 -t apache
So we have designed the following code flow that takes code from a developers laptop to SI and if that’s passing, we manually make a call to push to production.
We ended up with the following code > deployment flow:
Buddycloud helps you quickly add communication to your app. If you would like to try it out see Buddycloud Getting Started page.
It’s painful to realise the harsh difference between:
"I think I know how people use our website"
"Why is he clicking there? Can’t he see you have to click on the follow button before you can post? Aaaarch!”
User testing is painful: it shows up your false assumptions. The great news is that the sooner you know, the sooner you can begin sanding off the rough edges in your product.
There are some user testing services that charge $39 per test. This approach will cost you 50¢ per test and give you a video of a complete newbie using your website.
Here are the steps to begin testing:
I hope this helps you with your user testing. It’s helping us find out where we can improve at buddycloud.
Dodo has kindly offered a repeat of his popular Coffeescript intro course.
His session will get you ramped up with the fundamentals of coffeescript and he’ll do a code walkthrough of the buddycloud webclient code.
To join, add your name to this Doodle form: http://www.doodle.com/khnd7kwwe5rc65nt
We’ll do this through a Google hangout - so leave your contact details on the Doodle and we’ll email you when we fire up the hangout.
Your host. (photo taken by ft at the last bc hackerthon)
buddycloud is really proud to be working with two great students from Google’s Summer of Code program.
buddycloud has an event driven architecture (everything in buddycloud is realtime and events can happen on any domain that runs buddycloud).
Soon, developers who want to extend buddycloud will benefit from the new HTTP API: Denis’s HTTP API will give developers a nice way to plug existing JSON-based queries into buddycloud’s realtime architecture. buddycloud users will still have the "ooooh this is fast and nice" experience.
The buddycloud media server makes it so simple to drag and drop media into a channel and chat message. Media is magically permissioned to the person you are talking with or the followers of your channel. But simple-to-use will mean that Rodrigo will be working hard on a design that removes all user confusion and "just works".
I’m really looking forward to working with Rodrigo and Denis and to using their code in production.
Also, a huge thanks to Kev for coordinating and organising the Google summer of code. Without him, none of this would be possible. Thanks Kev.
Welcome Google summer of code programmers!