The Viewpointr Dev Cycle
Hey all,
In reconnecting with a friend, I was recently asked about how we handle some of the deployment / development related things at Viewpointr and I figured I would share it with everyone.
In the old days...
Not too long ago in the days of Prospectlinker we were a little more hap hazard about our development cycle. We would typically use something like Basecamp and Google Docs to keep track of what we were doing and what we had left to do. Basecamp worked well for a while, but it really wasn't designed as a bug tracker / feature planner so we tried Lighthouse. It's a great app, but we found it to be more geared for open source and decided to abandon it. For a little while we stuck with Google Docs and email but eventually moved everything over to Pivotal Tracker. Pivotal Tracker is bar none the best bug tracking / feature planning software tool out there. Seriously, like nothing even shakes a stick at it. If you haven't checked it out I would do so now, here it is again... http://www.pivotaltracker.com. Oh and by the way... it's free.
Each week Pivotal tells me what stories are on the board, and working as Agile like as I can, I pick the ones that I want to work on first. I typically pick the hardest ones on Monday and then move to the easier ones as the week goes on. As long as all the stories get done throughout the week we are happy.
However, we are proud to admit that we are obsessed with feedback and add stories that our users have requested even if that means pushing back what we had planned to do that week. The key is finding a balance between keeping your users happy and having a clear sense of what you want the application to be. We can't add every feature that gets requested, but we can treat each user as an intelligent and unique point of view that adds perspective to planning, design and evolution of product. Since the whole team gets invovled it really works well. It's a lot of fun :)
Day to day
We use Git and GitHub so I spend most of my day in the command line. I typically make a new branch for each story that I am working on. This is considered a best practice as it really helps to encapsulate each feature in case you decide to ditch it, or in case you need to jump back to the production branch to push a hotfix. The Pro Git book by Scott Chacon is a great resource for Git best practices. I highly reccomend it.
I practice TDD / BDD; currently using more Shoulda than RSpec but I like to mix it up. I find Shoulda better for models and controllers, but use RSpec for functional tests with Cucumber. For example, some of our Pointing logic can get a little hairy as the numbers get big fast, so I have a handful of scenarious and specs for those critical parts. Admitingly, I find myself sometimes having to go back and write a test but this is getting less frequent. I have been trying to stay disciplined over the past few months and it has paid off. Besides, there is this other developer named Kent who seems to think it's a good idea ;)
When a feature is done, it is merged into a dev branch where more tests are run. Once it passes dev, it gets merged into master. We don't have a continuous integration server but plan on having one soon. Instead, we push to a staging site and test there until we are happy. Then we move it over to production.
Deployment
We use Engine Yard Cloud to manage our deployment so this part is very easy. I remember the good old days of Capistrano and Vlad the Deployer but Engine Yard takes care of all that now. Using a service like Cloud allows me to focus on development rather than system admin stuff which is great. Besides they have Jason Vantuyl and Ezra Zygmuntowicz behind them... sorta hard to compare my sysadmin skills to theirs :) Engine Yard worship aside, we have also had a great relationship with OCS Solutions and would reccomend them too. The Cloud isn't for everyone and we are even noticing some draw backs particularly as we are heavily invested in email but every great problem has an even better solution and we are working towards that end as we speak.
I live in Toronto so we typically deploy every night at 11:00pm EST. We will probably change this in the new year and move to a bi-weekly or weekly deploy, say on Sunday night (after football) but I'm not sure yet. Stay tuned for updates.
In conclusion...
I hope this little look into how we do things at Viewpointr has been helpful. We are passioante about what we do and try to use the best tools and practices to make sure that we can provide our users with a high quality and engaging site.
Let me know if you have any questions and make sure you keep giving us feedback.
Next week, we will talk useability... but for now, I bid you adieu.
Thank you,
Kent
