#buddycloud

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.

Automatically.

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.

Core services and Docker deployments

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:

Developer checks out https://github.com/buddycloud/hosting.git works on their change or feature branch.

when they are ready to test in a system integration environment they commit back to the dev-candy branch

Github triggers a Jenkins hook that fires off the scripts from https://github.com/buddycloud/buddycloud-package/tree/master/projects/hosting/docker

Jenkins tries to build the project

If successful Jenkins calls the docker scripts that deploy to either production or system integration environments

the service is started and visible on https://hosting.buddycloud.com

It's painful to realise the harsh difference between:

"I think I know how people use our website"

and

"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.

The trick is a combination of Amazon's Mechanical Turk and Screencast-o-matic.

Here are the steps to begin testing:

Sign up and create a HIT (Human Intelligence Tasks) in Mechanical Turk. For simplicity click on Create Hit Individually The other forms are too complicated for our needs.

When creating your HIT, in Answer Format, select: File upload. Our users are going to upload their screencast here.

Provide detailed instructions. Here's a current test that we are running at buddycloud:

Go to http://screencast-o-matic.com/   and hit "start recording".

Go to https://beta.buddycloud.org  and hit register.

(screencast-o-matic will record your voice) tell us about what you see and how you find the registration process.

Log in at https://beta.buddycloud.com

Tell us what you think of buddycloud. What is your first impression of buddycloud?

Follow a channel on the buddycloud website.

How could we could improve this sign-up service.

Go back to your screencast-o-matic screen and stop the recording.

Upload your screencast-o-matic recording to this Mechanical-turk HIT's upload box.

Have a lovely day!

Set a rate per HIT. 50¢ per test gets a good response rate.

Mechanical Turk will email you when a new file is uploaded. Download and share with your team. And don't forget to approve the HIT so that your worker gets paid.

I hope this helps you with your user testing. It's helping us find out where we can improve at buddycloud.

Happy testing

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.

buddycloud is really proud to be working with two great students from Google's Summer of Code program.

Denis Washington will be building an HTTP API to buddycloud.

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.

Rodrigo Duarte will be building a buddycloud media server (GSOC proposal).

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.

#buddycloud #xmpp #socnet #ddfon buddycloud hackathon for thinkers and makers | buddycloud