We're hiring! Check out our currently open positions »


A friend of mine sent a post by Thomas Fuchs to me recently and I thought it was interesting. So, I decided to put together something myself, but focus on the development process, and a little of what happens around / after it. It’s a very lightweight overview of tools and processes that may be helpful to you when building a project or team.


The first thing that you need is some form of realtime communication tool(s). Everyone needs to be able to talk to each other easily, and down the line it could be linked to important notifications from other systems. HipChat and Campfire are two common tools for this, and then, of course, there is the lost dog that is Skype. Here is a decent overview, which may or may not be biased, from HipChat.


So, you can talk to each other - great. Now, you’ve begun planning things out, and need somewhere to store / track / monitor progress. Sprintly, Trello and PivotalTracker are good tools for agile workflows. If you’ve chosen HipChat or Campfire as your comms, then you can also hook up events in these planning tools to auto-post events to your comms. So, when someone adds a story / comment / bug, it’s pushed out to everyone. Sweet.

##Implementation You’ve started to code and you’ve probably grabbed Bootstrap or Foundation because of what you get out of the box. Stop. Take a look at your development environment, and see how you can improve it and make it more efficient. If you’re using something like Vim, then learn more of the key bindings. Grab something like Syntastic so you’re being given feedback as you code and plug in a CodeSniffer plugin while you’re at it.

Start coding and use a DVCS like Git or Mercurial. Set them up on GitHub or BitBucket, or locally via something like GitLab. You could even use something like git-flow to manage your branching. Hook them up to your comms via post-commit hooks so now you have notifications flowing for commits, tied to your stories from your planning setup.

##Testing You’re coding via TDD / BDD (or maybe you’re not because your monitoring is awesome?) and you have some unit / functional / integration testing set up locally, maybe with PhpUnit, JUnit, etc. If you’re using Rails then you’re already laughing. You’re also looking at things like Selenium and Browserstack for headless and VM based testing.

So, you’re happy with your own code, but what about when you integrate with the rest of your team? Time to set up some continuous integration awesomeness using something like Maven, Jenkins, Circle CI, or TeamCity.

Now, when someone commits code the tests are run automatically, and when they break the build, your comms are notified so you know who to shout at. Boom!

##Deployment Right. Everyone’s code is being automerged and you know who breaks builds the most. Now, you need to get the releases out regularly and reliably. You can use things like Fabric, Puppet, post-commit deployments or just use your CI server, that you’ve already set up, to push green builds. Done.

##Monitoring / Notifications So, finally you have an auto-testing-building-deploying project of awesome. Things can still go wrong and they nearly always do. This is where you start monitoring your servers with NewRelic (which is free for Standard on AWS btw) or AppDynamics, your network with Boundary, and your log files with LogEntries. And because you need to know what’s going on, you’ve hooked them all up to something like PagerDuty.

##Scaling Your auto-testing-building-deploying-selfmonitoring project of awesome is going well. People love it and you know this because you’re using Intercom. Your servers are coming under load so you need to scale. You’ve set up on AWS so you hook in your notifications to kick off launching new instances to deal with the load, or better yet you have set up on Elastic Beanstalk … or maybe you let the guys in EngineYard just take care of that completely!

##That’s a simplistic overview Yeah, but it’s an easy way to list tools, processes and services that I like :) I’ve also left out a few areas that I might come back to again. Hopefully, some of it is useful. If you can think of improvements, why not add to it?

  • tools
  • process

blog comments powered by Disqus