This post discusses some of the tools I use for my projects. It’s here to help me reflect on my workflow and identify areas where I could be doing better.
I’ll start with version control. Like many people out there, I use git. Since the majority of my work is closed-source, the upstream is hosted on a private server which I access over SSH. There’s a private GitHub repository downstream, but that’s mostly for looking at the code via a browser, and other goodies like the Wiki.
It has worked really well for my one-man projects; but not as well for my most recent team project (still “good enough”). There are several downsides of our approach. The first is you need to be really confident with the command-line client in order to interact with a remote server via SSH alone. There is a steep learning curve, so finding people that are comfortable with this setup is not that easy. One careless command and a rookie team member has just force-pushed your changes to the remote master and clowned up the repository for the rest of the team (yeah, that actually happened to us. Luckily, we recovered quickly.)
That little anecdote brings me to the next downside: git offers very little granularity in access control out of the box. You can use UNIX directory permissions to control access for the entire repository (e.g. read-write for some people, read-only for others) but that’s about it. It isn’t a huge deal if you’re working on the project by yourself, but becomes a problem if other people are working with the same repo.
There are various solutions to the above problems. For example, GitLab allows you to host a UI like GitHub’s on your own server, solving both problems but introducing significant maintenance and resource overhead. It’s a bit too much for me. Gitolite is a much simpler solution that introduces access control into the existing git stack.
A third downside of the current approach is that it does nothing to enforce a particular worklflow. People can commit whatever (ideally, good code!), whenever (ideally, as soon as possible), and wherever they want (mostly to the master branch). Reviewing work is also not trivial. Such an environment requires significant discipline from the team members. People pushing code have to make sure their commits are legit, and the team lead has to remember to review pushed code. We have various other tools to help us with this (e.g. issue tracking, unit tests, automatic builds - more about that in later articles), but it’s not an ideal solution.