A few months ago we put together some processes and tools that we'd been using in isolation (mostly). We like what it gave us, and you might too. Ruby on Rails and Linux hosting (from Brightbox) are our tools of choice, but I'm sure the principles will translate to other technology.
What we were aiming for, is a way for the team to keep working without having to manually update issue tickets, deploy the app or tell the team that features are ready to be tested. Instead, they can just keep coding.
Staging
I doubt this is news to anyone, but setting up a staging version of your project is massively helpful. It will help you isolate progress that isn't production ready and acts like an air-lock, allowing you to check and double check a feature/change/bug-fix before it's pushed live. Your product owner/client will like it too. We use Scrum so changes are welcome and frequent. Having staging versions of our applications lets the owner test and refine before anything is shown to the world.
We like to use the master branch of our repo as the deploy point for staging. We have a production branch which is updated with production-ready changes when they're ready to be pushed live.
Automated Deployment
If you're not using a version control system, you should be. We use Git, because it's amazing. All of our project source code is hosted with Github. Again, it's amazing.
Using a combination of a Sinatra app called Pushr and Github's post-receive hooks we configure our staging version to automatically deploy, whenever a change is pushed to the master branch of our repo. This helps in a few ways:
- A deploy takes place when any team member pushes to the repo. That means we don't have to configure ssh keys on every developers mac. As long as they can push to Github, they can deploy to staging.
- You can't forget to deploy your changes to staging. It just happens.
- Testers can be sure that the staging version of the app is always up to date (as recent as the last commit).
Issue Tracking
There are lots of good issue trackers out there (Lighthouse, Sifter etc..). At Fudge, we use a tool called Glu. It's our own product that we'll be releasing at some point this year.
A few, specifically Lighthouse (and Glu) integrate with Github. When a push is made to the repo, the issue tracking app is informed (through a post-receive hook) and tickets are automatically updated.
Here's an example:
- Jim commits and pushes to the repo with this message, "Fixes #251 Validation added to form".
- Github contacts the bug tracking app and updates the status of ticket #251 to resolved.
- The bug tracking app does it's stuff and informs people that the ticket has been updated.
So, if your issue tracker of choice supports this, you're in good shape. Not having to manually update a ticket after it's been worked on saves a massive amount of time. Seriously.
Deploy notifications
We use a Rails plugin called CapGun. It integrates with Capistrano (used to control deployment). Whenever a deploy takes place (keep in mind we already automated staging deploys with Pushr), an email is sent to everyone on the team. This email lists all of the commits that were included in that deploy. It's incredibly helpful during testing/QA.
I'm Scrum Master on most of the teams at Fudge, so for me to be told about progress on staging like this is awesome. I don't have to keep asking where tickets are up to and asking people to deploy. I get a nice email whenever this happens.
Conclusion
This might all seem a bit complicated, but a few hours spent configuring this at the beginning of a build saves hours later on. The point of this is to let people build, test and refactor without having to worry about deploying, updating tickets or letting the team know about the status of the staging site.
Obviously the tools I've listed aren't the only options, but if you're using Rails they're a good start.
Resources
