About a year ago Graham and I went to Google IO to learn about some upcoming technology and meet some tech folk in the valley. The experience was great. We met a bunch of great people and got our hands on some new technology. Beyond everything else, the best thing we got out of that conference was a technology/development mentor & a new startup development process.
As SoapBox grew, we tweaked our development and deployment process as needed. At the very start we used a cheap hosting provider and learned to deal with their limitations. We knew there were other ways of doing things, but they seemed to add complex rules and process. This worked for us, so why fix it?
We then met Ian at Google IO, who agreed to share some of his insight from scaling over and over again. Ian is a senior web developer/architect working over at Sendgrid. Ian is awesome and we really take his advice to heart. He deserves the credit for a lot of what you see below (including the joke I shamelessly stole from him).
Below are the 5 things we changed in our startup’s development process to better manage the growth of our business. At the end you’ll find some (unscientific) results of these changes in case you also think it will just add complex rules and process.
Graham is planning additional posts in the future to go into more detail on how each step has allowed us to develop and push code at a faster pace while increasing the quality of our code. This should serve as a good outline of how we work.
Step 1: use git(/github) properly.
- Separated out our app into better repos. This is still a work in progress.
- The “Production” branch is what is currently deployed live on the server
- “Staging” branch is what’s queued to go live and should always be deployable.
- Everything else is separated into it’s own branches. New features, maintenance, and hotfixes which should have short but descriptive names
- Features branches are prefixed with “F-“
- Maintenance branches are prefixed with “M-“
- Hotfix Branches with “H”
- We merge our branches into staging. Then Staging into production. Team code checks at both merges. (Hotfixes can go backwards)
- We use Pull Requests like how github does:
- If there is a large feature (an “Epic”) we open an issue for it first. In this issue we plan out what’s the best way to tackle it and some sketches if it requires UI changes. This allows the team to chime in before anyone gets too far down the wrong direction.
- When we’re ready to develop that feature, we open (or convert that issues to) a Pull Request against Staging. We do this right after creating the branch. This means every time we commit there is additional visibility.
- As we code we add screenshots or ask questions to the team. It becomes a sort of living history (think Facebook wall) of that feature.
- We’ve also added our Roadmap to the Github Issue Tracker and our sprints to the milestone area. It allows us to assign issues to sprints and plan our next two weeks.
Step 2: frAgile Development
While not necessarily “agile development”, it’s similar. Ideally it ends up working out to 10 day sprints though sometimes Day 10 is just work.
- Day 1 : sprint planning day.
- Day 2 : Scrum. Wire-In. Test. Push.
- Day 3 : Scrum. Wire-In. Test. Push.
- Day 4 : Scrum. Wire-In. Test. Push.
- Day 5 : Scrum. Wire-In. Test. Push.
- Day 6 : Adjustment Scrum. Back log grooming. Test. Push.
- Day 7 : Scrum. Wire-In. Test. Push.
- Day 8 : Scrum. Wire-In. Test. Push.
- Day 9 : Scrum. Wire-In. Test. Push Feature. Review Stats for Demo Day.
- Day 10: Demo & Analysis & Reflection & Sprint Planning Day.
This combined with Step 1 has been a large positive change in our day-to-day development
Step 3: HitSend Robot Army
- We created Staging Deploy bot who listens for changes to the code on the SoapBox Staging branch. If there is a change, he pulls the code and places it on the server. I’m amazed at how quickly it happens.
- Production Deploy bot does the same thing for production.
- We created Hitbot which is a renamed hubot campire chatroom robot. He is connected to our github account and can give us information about our repo if we want. He will be the center of some future hack projects I’m sure.
Step 4: Hive Mind Planning
- For large projects, like our new API, we write out the documentation first. This acts as a proposal document so we’re not inventing it as we build it. The guidelines should allow us to agree on the conventions and allow us to work more in parallel.
Step 5: Test all the things
- We set up a private Travis-CI under HitSend to build and test SoapBox on their environment. It’s fairly easy once it’s working.
- It tests code on branches: Production, Staging and Pull Requests to those branches. Here is how it works into our development flow:
- Create pull request / commit code to a pull request
- Travis pulls our code and configs a VM based on our settings
- It runs PHP Unit and PHP syntax checkers for the php code.
- Travis CI tells github whether or not the test passed. It changes the “merge” button to green if it did or grey if it didn’t and provides a link to the failing test log. See Github’s description of this feature
- Travis CI then communicates through to us via Hitbot on our campfire chatroom.
- What’s left for us now is to build out our unit tests. While we pass syntax and jshint there are only a handful of tests.
Overall the development delorean ride from 1995 to 2013 has been extremely positive. I’d love to say Step 6 is “???” and Step 7 is “Profit.” but the truth is, all has helped the business throughout each step.
These may not be scientific, but they’ve been noticeable.
- Using git properly increases the quality of our code and codebase, as well as quality of life. We never have to stress if we need to do a hotfix. Branch off production, fix, merge, done. Back to your feature branch.
- Agile has given us just the right amount of focus. We’re able to commit to a task for 2 weeks without having to worry too much about other development task. This has had a noticeable affect on the quality of our code and features. Focus.
- As an under-slept small team we’re notice changes of inefficiency at a grander scale than most. Saving Graham and hour a day or week is a huge, noticeable, deal to us. The Robots do this, and will hopefully do more of it as time goes on. Robots also make less mistakes… which means we never have to worry that all the required files were pushed into production.
- Step 4 and 5 I believe will pay off over the course of the year, especially with as our development team grows. I think it will give them more direction on how they’re doing and create a more scalable workforce. I think it will also give us a larger degree of confidence when we push our code to the server.
So that’s our startup development process. How does your company G.S.D.? We’re always looking for improvements to our process. While we think it is good, it isn’t perfect. We want to know your suggestions for improvements!