Committing, Testing, and Releasing Code

[ This the second post in the Managing Source Code at 8BIT series. Part 1. ]

One of the challenges of working in a distributed, bootstrapped startup is that it takes a little bit of trial and error to find a solid process for getting work done. I wouldn’t say we’re optimal, but we do have a solid methodology in place (and it’s taken us a couple of years to refine).

We’ve gone through a several different project management applications, source control systems, and ticketing applications before landing where we are today.

On Permissions

Currently, we’re a Subversion shop. We’ve been using Codebase for sometime now and have few complaints about it. The UI is solid and the built in ticketing system is really nice.

Within codebase, we have three projects:

• Tools are any utilities, plugins, or scripts that we’ve written (such as the Konami Code) that we’ve written and used but aren’t full-fledged products.

• WordPress includes all of our WordPress-specific work – themes, plugins, etc.

• Internal Applications are applications that we’ve written or prototyped internally that have never been released.

Only three people on the team can commit code to any given repository: Michael, Jared, and myself.

As a team, we attempt to fully own our respective areas of the business. This is the same reason why Chris interfaces with our accounting partners, why John communicates with business and marketing related efforts, why Michael heads up our forums, and this is exactly why only those of us that are actually building the project have keys to the repositories.

A Survey of Our Workflow

When it comes to actually doing product development, we follow a relatively formal process for committing, testing, and tagging code. All development methodologies aside – at least for this post – here is a survey of how we manage our release cycles.

Committing Code

Though our repositories are Subversion-based, we only use the trunk and the tags directories. We’ve yet to require a need for branching and I’m highly against doing things just for the sake of doing them. I’d rather start at ground-zero and put practices into place as needed.

All code that is under development is committed to the trunk. At any given point during development, we can export the trunk and have a snapshot of the current state of the project.

Once we’ve gone through our standard testing cycle, the code is tagged at a specific version and then exported for release. Since we typically plan on patching bugs and introducing new futures, the trunk remains and we continue the process throughout a project’s lifecycle.

Testing Code

Once we’ve gone through a full development cycle and the current state of the project is at code complete, then Michael begins testing. He does an export of the code in the trunk, sets up a staging environment, and then works through the testing spreadsheet he’s devised.

For each issue that he discovered, tickets are then created in Codebase and assigned to me:

At that point, I’ll triage the tickets to determine if they are legitimate issues, if they can be pushed back to another version, if they should be assigned to Jared (in the case that it’s design-related issues), or if they should be worked.

Assuming they should be worked, I then complete each ticket committing code for each resolved issue. I then assign a ticket back to Michael and mark as ‘Complete.’

At that point, we repeat our process once again. Michael runs through his testing spreadsheet again – if the tickets I’ve assigned him pass, he marks them as ‘Verified,’ otherwise, he’ll assign them back to me for review and resolution.

Once all tickets are closed, we tag the code at a version and export it for release. Chris, Jared, and John usually then take off with their marketing efforts (landing pages, eCommerce configuration, marketing emails, etc).