A few weeks ago, we at Green Gorilla Apps ran a one-week trial for working remotely. We’ve been in the same office since we started in 2012, so it was a big conceptual leap to go from daily face-to-face contact to working from home.
Fellow Gorilla Paul has already written a post on the results of our first week, but I’ve had a few questions from developer friends about how we handle day-to-day operations, which I thought I would answer in another post. This is relatively technical so, if it’s not your thing, send it over to the nearest techie.
In the meeting before we started our week’s trial we discussed what needed to change for us to be able to perform our day-to-day operations when working remotely. Kyle, one of our developers, pointed out that we were already set up for remote working with all the various tools and processes that we used, it’s just that we’d been running it from the office.
Here are some of the core processes we subscribe to, and how they helped us to work from the comfort of our own underpants. Sorry, home.
Git
Honestly, we couldn’t imagine running a software company without using version control. That’s the kind of thing that causes you to wake up in a cold sweat, before the sweet relief of reality kicks in.
We use Bitbucket for all of our git repositories, and we have a backup Gitorious server, just in case Bitbucket is unavailable when we need to deploy urgently. We use pull requests to track code changes, so all developers have at least a basic familiarity with all code that’s being deployed.
The great thing about git is that it’s designed for remote working, so that was an easy win.
Continuous Integration and Deployment
We use the trusty Jenkins continuous integration server for building our projects. This means running tests, analysing code quality and producing metrics. If the builds pass then the code is then automatically deployed to either a staging or production environment.
We consider continuous integration and deployment to be essential processes for a remote team, as it gives complete visibility to everyone regarding the status of each project. It also gives the whole team responsibility over the health of a project, and brings otherwise hidden failures out into the open.
Error Tracking
We pride ourselves on our quality, but bugs are inevitable. If we can’t eliminate bugs, we can do the next best thing: know about them before the user has even realised that something’s gone wrong.
There are plenty of error tracking tools out there, most of them subscription based. We opted for a open source, self-hosted tool, Errbit. It uses the Airbrake API, and catches both server- and client-side errors. It then alerts us immediately, allowing us to respond quickly.
Cloud Servers
We manage over 20 servers, most of which are hosted with Digital Ocean. Managing physical servers would be a barrier to remote working, because we would need to be available on site for emergency repairs or maintenance. Cloud servers give us the flexibility we need to be able to scale, while inherently being appropriate for remote management.
Our servers are configured using Ansible, which ensures that they are all set up in the same way. We use Zabbix to monitor the servers, which alerts us when there are any problems or unusual activity (e.g. unexpected reboots, disk space filling up, resource overloading, etc).
We use the same image for all servers, Debian 7 (Wheezy), configured with systemd. Systemd is the most effective system management daemon we’ve come across, as it’s reporting and auto-restart policies are excellent. The one thing missing is specific reporting on process activity (e.g. if a process crashes and restarts), so I recently wrote a tool to monitor these changes and send alerts, SystemdMon.
Communication
Ultimately, this is the most important part. Communication seems easy when you’re in one office all together, and is suddenly a hot topic when remote working is on the table. This is the main question people have when asking about the way we conduct our remote team.
We use Slack for instant chat, which takes care of about 90% of our communication. It’s the main way in which we talk to each other, but we also use it as a complete base of operations through the use of notifications.
It’s critical that we know what’s happening at all times, so we get alerts for the following: Bitbucket pull requests; new commits added to Bitbucket; Jenkins builds; capistrano deployments; Zabbix server monitoring alerts; systemd alerts (through SystemdMon); and Errbit error alerts.
We have several rooms for different conversations and notifications. One room is our general chat, another is mainly for developer alerts, and the other is for cat GIFs and humorous things from the internet.
Alongside slack, we use Google hangouts for all of our “face-to-face” meetings. We have two short daily meetings, which helps us to keep track of what we’re all working on.
The general consensus among the team is that communication has improved. In an office it’s easy to have a one-to-one conversation with someone that might be important for the rest of the team to hear. It’s also easy to forget things that have been discussed verbally. Since most of our communication is now text-based, we can simply go back and check what was said. It’s also a less intrusive form of communication, and slack does a good job of grading alerts depending on whether you’re mentioned specifically or not.
None of the processes I’ve mentioned are particularly ground-breaking, and neither are they specific to remote working. Even if you work in an office and don’t see that changing any time soon, they’re good things to implement. Removing any dependency on the office makes the business much more flexible.
Our one-week trial never ended. It was such a success that we haven’t gone back to the office, and we can’t see any reason to do so.
Thanks for reading, and we hope you’ll consider giving remote working a go.
