The Cloud

Don’t get me wrong, the “Cloud” is great. Being able to utilize existing apps and not having to worry about updates or security is a huge time saver. But when it gets down to it, “In the cloud” is a buzz term. When translated to laymen speech it means “Storing your data and running your applications on an offsite server, somewhere”. It’s that “somewhere” that is a legal gray area for us, and for certain clients. For example; let’s say we’re working on a project for Microsoft, but are storing documents and files on Google servers. The two companies can (and do) collaborate, but what if they don’t on this project? And we’re storing sensitive Microsoft information with Google? It could cause legal issues if a dispute ever came up. This is the primary reason why we choose to self-host the vast majority of our infrastructure. The services we self-host include a Git server, bug tracker, wiki, file syncing server, and a custom built timetracker. Having a local server host all these services allows us to be extremely agile in development and with our workflows.

Infrastructure

The first step with self hosting is the server. Our first development server was a Compaq tower computer. With a blazing fast 3200+ AMD Athlon processor, 1GB of RAM, 160 GB hard drive, and DVD RW with Lightscribe running Windows XP.

By today’s standards it wasn’t pretty, but it worked, and having a team of 5 we didn’t need a powerful server. When I started looking into self hosting services like Git or a bug tracker, it quickly became evident that having a Windows system would not work, since the majority of the open-source community, understandably, revolves around Linux. I had no choice but to dive into learning Linux.

Step one was setting up a VM running ubuntu. Using a VM was great, since I could test and break things without affecting my main development machine. It also allowed for the ability to test new features or programs without affecting the main production server. It was only recently that I migrated to a dedicated headless linux box to run our server. However, I still keep a local clone in Parallels for testing new additions or major updates.

Git

Back when I started with gskinner (almost 10 years ago as I write this), it was a small company with only a few employees, and there was no source control system in place. Updates were handled via email, ftp, or chat clients, and at times entire projects were stored on a single employee’s system with occasional DVD backups.

I had used CVS and SVN at a previous employer, so I installed SVN on the old Compaq tower that was used as a file-sharing server. At first, we used VisualSVN to manage all our SVN repos. It had ok user management, and let us create repositories easily. The down side was that it had no remote management, so changes involved someone going to the server room. It suited our needs for a few years, until Git started becoming the the source control solution of choice; we quickly jumped ship and switched everything to Git. Our first Git server was a little Ruby on Rails application call Gitorious. At that time it was one of the few web based Git servers that could be self hosted. Unfortunately it wasn’t perfect, installation was hard, updates were harder, but it worked, and suited our needs for around a year. That’s when I found GitLab, another Ruby on rails application. The difference was this one was very easy to install, easy to update, and had a fast release cycle. So we again jumped ship and switched to this new source control server, and we haven’t looked back since. Interestingly, Gitorious was eventually bought by GitLab.

Bug Tracker

As any developer knows, bugs in software are inevitable, so matter how hard we try to write perfect code the first time, those little buggers keep popping up. Every development company uses a version of bug tracking software: Some are custom, some are purchased, and these days, many are “In the Cloud”. At first we tried using Mantis, but after a short evaluation period we knew it just wasn’t the right tool for us. It was poorly designed, slow, and in general hard to use. We are huge fans of JetBrains, and many of our developers use WebStorm or PHPStorm for their daily work. That led us to YouTrack, a fantastic developer-oriented bug tracker that yes, can be installed on a local server. We tested the trial out for a few weeks, and everyone loved it, so we dumped Mantis and switched to exclusively use YouTrack.

Wiki vs Google Drive

Organizing information is a necessity for any company. We use Google Drive for our living documents, as it offers many benefits over static files. For example, allowing multiple people to view and edit files, easily sharing with clients, suggestion-based editing, and read-only sharing. This allows for seamless collaboration on a variety of documents. Documents that are considered sensitive, or that could pose potential legal issues, are not stored on Drive, but rather our self-hosted file server. In cases where documents do not need regularly updating, and serve more like internal documentation, a private Wiki is a much better choice. Although multiple wikis exists, MediaWiki is by and far the de facto standard of ‘wiki’. If it’s good enough for one of the largest sites on the internet, I guess it’s good enough for a team of ~20. The wiki also maintains fun pages like “Where to eat” and “History of projects at gskinner”.

Files

Sharing files between employees is a must for any company, and being a full-service web company we need to share everything from code to large .psd files, and everything in between. We initially tried Git to share binary files, but that option went down in flames. Git is designed to handle code. Sure, it can handle binary files – but when it comes to managing GBs of data, it falls down. So we moved on to a program called Seafile, at first it seemed like a great option, but as soon as more than 2 people were using it, things became slow, files were lost, and many changes were overridden. So… not a great team option. Then, we found OwnCloud, billed as “your personal cloud”, we use it only for syncing files. This is one case where self-hosted is not necessarily better, mainly because of the huge resource and bandwidth requirements needed to share files. At the time of this writing, GitHub announced git-lfs. Its looks intriguing and we will be investigating using this instead of a separate files server. The power of Git, with usable large file storage? Sounds like a win-win to me.

Keeping it updated

As I initially mentioned, one huge benefit of using the so called “Cloud” is a third party will maintain the server, and deal with updates, and security patches. Being self-hosted, that responsibility becomes yours. Let take GitLab for example: As our code hosting server, every project we build has its code there, so it needs to be secure and kept up to date. The GitLab team is great with releasing new, stable versions monthly, and in turn, our server is updated regularly to ensure we have the latest security updates and bug fixes. The updates aren’t limited to the application level, but also the OS level. Ubuntu is constantly pushing out security updates, new features, and versions to the community – so running sudo apt-get update && sudo apt-get upgrade; is a very common practice for any ubuntu server administrator. Security updates are installed automatically by the system. It helps during those busy times where our server might not get the love it requires, it gives peace of mind that at-least our server is secure.

Backups

No local server installation is complete without a solid backup system. No one can account for every contingency. What if … A hard drive dies? There is a massive power surge? A water leak? Fire? With all these uncertainties it would be irresponsible not to maintain remote backups. In addition to backing up all of the local servers files and data, our remote web server is also backed up locally,and synced with the rest of the data to our current backup provider, CrashPlan. Even though this is technically “in the Cloud”, all the data is encrypted locally before ever ending up on CrashPlan servers. Utilizing a custom key, not even CrashPlan has access to the data, giving us peace of mind that even our backups are safe and secure.

Summary

All the above services have cloud alternatives, Git has GitHub, Bitbucket, and GitLab. Bugs has a whole host of options, even YouTrack has a hosted option. Files has no shortage of options: Dropbox, Box, Google Drive, S3, OneDrive… the list could keep going. For all the services, it seems like new open-source alternatives are being released every other day.

Our switch from SVN to Git was not painless, but in the end we have a far superior source control system. If tomorrow a new amazing bug system is released, we could easily jump ship to it. As touched on in “Automation in Your Daily Workflow” or “QA for the Modern Web”, at gskinner we find it better to stay agile in everything we do. It keeps us on our toes and helps us not fall into traps of running archaic software just for the sake of keeping our workflows familiar.

What sort of systems does your company have in place to manage day to day workflows? Let me know if I missed any great options, or if you have any thoughts on the ones I mentioned.