Reading Time: 5 minutes
As a director of engineering with Sears Home Services, Ward Vuillemot is part of a Seattle-based team of about a dozen developers. While the company itself is focused on in-home repair and installation nationwide, Vuillemot’s toolkit involves a mostly Ruby on Rails stack with some Java thrown in.
“We’ll use whatever languages and services make the most sense for us,” Vuillemot said. “As much off the shelf as possible.”
Own your devops but keep it simple
After trying a few different options, he landed on Codeship for his team’s integration and deployment service. “While I want us to own everything — we do our own testing and QA, basically from soup to nuts — I didn’t want that to be a huge tax.”
Vuillemot described himself as having “a very low tolerance for things going bump in the night.” It’s a character trait that’s prompted an overnight migration for the team from BitBucket to GitHub, for example.
Codeship, Vuillemot said, was up and running in a matter of minutes. “Since then it’s been a delight to be able to use, even as I come up with different ideas,” he said. “It’s always possible with Codeship, and it’s always possible with a few lines of code.”
Vuillemot’s team is striving for service-oriented architecture; they’re currently maintaining a handful of services and will probably use more as the team grows. Other continuous integration and deployment services led to a lot of configuration touch points. “Getting those all up and running and making sure that things worked became a little onerous,” Vuillemot said, especially considering the growth of the team. “And then when things broke, it wasn’t always obvious — it became a little black magic at times.”
On the other hand, Vuillemot appreciated the ability to point Codeship to a repo and be done. “You say, here’s the stuff I want you to install, do a bundle, whatever, if we’re using Grunt, install Grunt, and then off we go. That was huge.”
The deployment aspects of Codeship versus other places also meant an end to writing custom rake scripts. “Which wasn’t horrible,” Vuillemot admitted, “again, just a maintenance issue making sure all these repos are congruent with each other in terms of our deployment hygiene.”
Fail fast, learn deep
Vuillemot’s team uses Codeship to manage the branching between staging and production automatically — Heroku for staging, AWS CodeDeploy for production — as well as handling the multiple steps in their deployment cycle.
“For example, when we go off to staging through our master branch, we automatically trigger a build on our integrations repo,” Vuillemot said. “We basically have an rspec repository that just does black box testing on all our staging. So the moment we deploy anything to staging, it automatically triggers that other build to fire off, which basically hits all our staging to make sure everything is still working. And that allows us to deploy to staging with deeper confidence. If our integrations aren’t passing, we’re not even capable of deploying to production. So that’s a huge bonus to us.”
Especially when you consider how frequently the team as a whole deploys. Vuillemot described himself as the kind of person who likes to write three lines of code, test it, and commit it. “So if I commit twenty times a day, then it gets deployed twenty times a day. Multiply that times even just a handful of developers, and you’re talking many dozens of times per service per day.” As far as production is concerned, even now Vuillemot estimates they push four to six times a day.
Because every step of the process becomes a line item in Codeship that gets greenlit as it gets passed, Vuillemot uses Codeship to easily identify exactly where in the process a build breaks. “It’s not an explicit step,” he said, “but because it’s a command line step, it’s very, very easy to diagnose if anythings goes wrong.”
He’s even used Codeship’s capability to remote shell into the VM. “I’ve only used it once or twice,” Vuillemot recalled. “And the second time just because I could. I thought it was fun and sort of geeky.”
The goal, he said, is always to reduce the lead time to production. “Always roll forward, never roll backward.” As a result, Vuillemot said that Codeship is fundamental to his team’s philosophy of fail fast and learn deep.
Flexible, simple services speed up conversation
As a company, he said, you’re trying to have a conversation with your customers your business folks, and your design. “Anything that puts a lag in that conversation means that things get wonky. That typically is what drives a lot of requirements, rework, etc,” Vuillemot pointed out. “So the fact that Codeship lets me go as fast as I can have a conversation through the code means that I have zero lag between me and my customers and myself and our designers. And I think that’s really critical in keeping teams in the spirit of agile, which is ‘grow as you learn.’”
There are certain services, Vuillemot said, that people get giddy about. “People love GitHub, people love Slack — Codeship is probably the one that gets me the most giddy.” He said he’d much rather spend his time writing code that touches his customers, but he still feels responsibility for owning his services. “I don’t want to throw it over the wall to someone else.”
“Codeship allows us to own things we ought to own as engineers,” Vuillemot said, “but it makes it painless. I feel like you’re part of our team — the service, the attention to detail, the TLC that comes through with communication. I can’t wait to throw more and more projects into Codeship. Having so much flexibility and still being so simple is just awesome.”
Ward and Sears Home Services are using Codeship to speed up their development. So should you. Learn more about Codeship here.