More About Developer Discipline
I published a quote the other day, but didn’t really elaborate as to why I thought it was good.
I’m really bad at remembering a long series of repetitive steps. When building software, there’s a whole pile of things going on, and inevitably some of the necessary steps will get missed. At VendAsta, everyone’s committed to building high-quality software, and part of that involves crossing all the Ts and dotting all the Is. To facilitate this, we ruthlessly automate as much of the tedious, repetitive steps of building software. Here’s a few things that come to mind:
- Fixing bugs without having them logged in our Issue Tracker (Jira). I’m notoriously bad for seeing a small bug and just fixing it. We address this in two ways: first, you can’t make a check-in into Subversion without putting an issue number in the comment; and second, when we do code reviews, the reviewer is definitely going to comment on changes that are happening to unrelated files.
- Committing changes without running the unit test suite. As soon as you do a commit, our Continuous Integration server (TeamCity) does a checkout and runs the unit test suite. If you’ve broken anything, you get an email and feel shame for forgetting.
- Committing changes without writing new unit tests. TeamCity handles this too! As soon as you do a commit, TeamCity runs unit test code coverage on it and produces a coverage report. We review this periodically, and if there’s code that doesn’t have test coverage, we spend the time to fix that.
- Making a commit, but not leaving a comment on the associated issue. We’ve got a commit hook for Subversion that automatically puts a commit log on the issue associated with a commit.
- Missing a step when building the software. There’s a few steps to building our software (it’s not that complicated, but missing a step could result in weird deployment problems). We use Ant to automate the build.
- Screwing up the deployment process (or forgetting). There’s three different places we can deploy too: local development server, Google App Engine (demo/staging site), Google App Engine (live product site). We want the local development server to always have the latest version of trunk, and we selectively push revisions up to GAE. All of this is automated with the CI server. On commit, we do a build and push it to the local server, and we’ve got two manual CI targets to deploy to the different GAE apps.
All of this (and I’m sure I missed other automated tasks) means that we can spend more time thinking about developing software, and less time worry about tedious things we might have forgotten.
Automation tools that actually reduce developer work and memory load. What a concept.
It’s lovely! Sometimes it feels like it gets in the way, but that’s just because it’s forcing you to do things right (for instance, enforcing the rule that you MUST associate a SVN commit with a Jira issue).
Very nice automation of source code, do you have an approach for my biggest concern: Versioning of the database (structure).
How do you co-relate a structure change to a code revision?
Awesome question!
We’re using Google App Engine for my project. For App Engine, the data modeling all happens in Python, so we get “for free” versioning of the database structure (just by checking our Python code into SVN). For SQL-type databases, a simple approach (one used by Ruby on Rails, and suggested in “The Pragmatic Programmer”) is to version your database schema as text files — these become your master schema definitions and contain all of the CREATE TABLE statements required to build your database structure.
This only gets you half-way there though, because you don’t really want to create a new database for each build (and lose all of your customer’s data). Schema migration is a much trickier problem, and I don’t really have any good answers (but I do have time dedicated this sprint to investigate what has been done by other frameworks and what is in the literature).
[...] my previous post, I talked about the automated processes we use at VendAsta to develop software. Arguably, the [...]