Do you own a dog and work outside of the home? If you do, or even just know someone who does, you know that finding a trustworthy caretaker is of the utmost importance. With dog walkers in cities and towns across the U.S., the folks at Wag! have proven to be a source of reliable caretakers for countless fur parents. In three years, the company has powered more than one billion walks via its app for on-demand dog walking, sitting, and boarding, that boasts of millions of users.
Wag! recently signed on with GitLab to make the most of their engineering hours and bring their customers new features and updates at a faster clip.
From version control, to CI, to the full pipeline
Having previously used GitLab as their main source of truth for repositories, Wag! initially planned to return to the app solely for continuous integration (CI). But after giving it a whirl, they quickly expanded their strategy to include the use of other features.
"We started our GitLab project about seven or eight months ago," explains Dave Bullock, director of engineering at Wag! "The original idea was to just use it as our CI platform. But as we built that out, we started using it for more and more tasks, and ended up using it for our full CI/CD pipeline. That includes both our application, so the CI/CD that powers the API, along with our infrastructure. We use GitLab with Terraform to test, review, save, and deploy all of our infrastructure as well as the application on two separate pipelines. Every team uses it in their application, whether it's the Android application, the web application, the API, or our infrastructure; it's all being tested, built, and deployed through GitLab."
Streamlining to a single application
Part of GitLab's appeal stemmed from the ability to do everything in one place. Wag! was searching for an integrated solution that would streamline their development process, and they found it in GitLab.
"We were previously using a combination of Travis and other random technologies, and we just wanted something with a little bit better interface, a little more control, and something that we owned as far as the hosting and the management," says Bullock. "We really wanted to move towards a single, full-service application."
"We just wanted something with a better interface, a little more control, and something that we owned as far as the hosting and the management. We really wanted to move towards a single, full-service application."
The impact of that choice is also being felt on the infrastructure side. Wag!'s infrastructure engineers no longer have to manually stage and test their work. They are now following the same basic workflow that is used for their app, while integrating Terraform to manage their infrastructure.
"Basically, one of our DevOps team members will make a change, cut a pull request, and it'll be reviewed by the team. If it looks good, we'll say, 'Okay, cool. Merge it into master,'" Bullock explains. "If it's one of the modules, we'll tag that module, update the reference to it, and then the CI pipeline will kick off. It'll test the syntax, look for any security issues, and alert a Slack channel if there are any. It'll then stage a full version of the environment and test it. So, it stages all the pieces: the database, cache, and everything else, and tests it all to make sure that it works, just like we would be testing our production website.
"If that passes, then it allows you to see what your changes are going to do before you apply them," he continues. "We call it Terraform plan. So, it runs Terraform plan on each piece of our infrastructure, and it'll tell us something like, 'Hey, we see 34 changes and 2 destructions and 1 creation in this environment. Click here to review.' Then the group will review it and if it looks good, we'll apply it in production. Having that as a full pipeline is really great."
“Now it's so easy to deploy something and roll it back if there's an issue. It's taken the stress and the fear out of deploying into production.” – Dave Bullock, Director of Engineering
Easy learning curve
Some of the Wag! engineers had working experience with GitLab, while others had not. Nonetheless, Bullock found the onboarding of his teams to be a fairly easy process due to the intuitive nature of the interface.
"I think once you kind of understand how CI works, it's basically about following things step by step," he says. "Pipelines were a new concept to a lot of the team, but once you see it happening visually, it's really easy to understand what's going on, expand and add to it. It's a really useful interface. Seeing all those green dots or red dots makes it really clear what's going on."
Built-in security, shaving down test times and faster releases
As part of their ramp up in GitLab, the dog-walking service recently furled automated security scanning and license management into their workflow, with Bullock noting how "great" it is to have those features baked into the pipeline so that immediate action can be taken when needed.
Wag! currently issues three releases a day, with plans to bump that number up to eight or more. Since adopting GitLab, they have seen a massive improvement in the amount of time spent on the release process. What previously took 40 minutes to an hour to accomplish, now takes just six minutes.
"Traditionally, the release process was slow, fragile, and limited to only a few key release engineers who had access to 10 different systems to monitor, make changes, and log into to make updates and pull in the latest code. It was not optimal. Now it's literally a single pane of glass. A lot of it just happens automatically when you merge
master and tag it."
The release process time should improve even more once Wag! engineers switch from manually pushing parts of the release through to automating the process.
"Right now, we're still clicking through the interface and saying, 'Okay, do this, now let's monitor,'" says Bullock. "But I think as we become more comfortable with it, we'll go to fully automated deployments. Literally, just let it go and deploy. If we see an uptick in errors, we'll let it roll back on its own. But as it is now, it's so easy to deploy something and roll it back ourselves if there's an issue. It's taken the stress and the fear out of deploying into production."
Wag!'s engineering team has big plans for 2019. They are currently in the process of moving their repositories from GitHub to GitLab and are planning to switch from Amazon ECS to Kubernetes. This is all part of their roadmap to implementing DevOps.
"I think we're going to start working on the project in Q1 and it will be really awesome to have all the bells and functionality," Bullock says. "We're excited about Auto DevOps and a lot of new things GitLab has coming down the pipeline. We're going to push pretty hard on that this year.
"I'm a big fan of DevOps in general, so I think the closer that you can bring the development engineers to the ops side, the better things work," he adds. "I would love for every software engineer or backend engineer to take ownership of the environment that their code runs in, or at least be able to experiment with it and kind of instantly just spin up a full working environment that is the same as our production environment, which we do now, but not with Kubernetes. I think removing that friction is great."
Growing with GitLab
GitLab's releases are a treat the folks at Wag! look forward to checking out each month. The rollout of new features, which are partly determined by user feedback, tend to correlate with the engineering needs of the growing dog-walking and boarding service.
"I think it's exciting that as we're growing and adding interesting pieces to our infrastructure and application, we're seeing GitLab grow with your monthly release cycles," says Bullock. "Every month there's some new stuff that we're like, 'Oh cool, we could use that, that's perfect.' It's nice to have GitLab as a partner that's growing with us, and it's exciting to see the parallels of new features that you're launching and how it's solving our problems and optimizing things. There's all kinds of cool stuff, and every time we start using a new piece of GitLab, I feel like, 'Okay, that's great, we're really getting our money’s worth.'"