A while back, I wrote a tool called ZENv that’s used to keep Zoosk’s developer environment useful and up to date. Since then, it’s helped immensely in keeping things productive and minimizing the amount of hair-pulling that I’ve had to do. It’s recently been open sourced, so I thought I’d tell a little story about how it came to be.
Zoosk maintains an incredibly complex developer environment. We have two websites (desktop and mobile web) as well as two native apps (iOS and Android). All of these need to work with the same collection of back-end APIs and services. When I was hired, I had to set all of these up on my laptop to get started. . . and I met an enemy that I had previously fought at several other companies: the Developer Setup Wiki.
“Dear Lord”, I thought. “How much has changed during the last few years? This isn’t going to work.” And I was right. I found outdated terminal commands, multiple sources of conflicting information about which bash files to create, and even steps that were missing completely. When I was finally done, I thought I had escaped — that I was free! But it was not to be.
It turned out that the Developer Setup Wiki had been updated, and now I had command-line aliases that were different versions than the ones that some, but not all, of my coworkers had. Imagine my surprise when I tried to send a coworker a terminal command and it failed spectacularly! This system had to go.
ZENv, or ZEnv depending on your inclination, was born from two basic ideas. First, all setup should be automated. Second, dev environments should be source-controlled. What those ideas led to was a full-blown custom developer environment tool that worked for every single team at Zoosk.
The core process is simple: check all your dev tools and environment settings into ZENv instead of adding them to your personal
/usr/bin folders, and let ZENv do the job of hooking it into your environment. If you commit your changes, you suddenly have a working, repeatable dev environment that always stays up to date and that everyone can use.
In appreciation of how much ZENv actually helped, we crossed out the old steps on the wiki instead of deleting them. Now it looks like this:
With all developers sharing the same bin folder, dev tools have started popping up like rabbits. Do you need to clear memcache? A dev on the Web team wrote a tool for that. Test PayPal payments? The Payments team has got your back. Update all the Docker packages running in your VM? Somebody in DevOps thought of that ages ago. All of these tools are available to everybody as soon as one developer writes them, making working at Zoosk easier than ever before.
When we start a new project, we create a new branch of ZENv for it. Recently, we started working with AWS-hosted services, and by the end of the second day of the project four custom commands for working with Lambda had popped up on my computer without me doing a thing.
At this point, you might be wondering how a single install process like the one that I described can work across so many teams. In fact, it doesn’t — ZENv supports creating sub-environments with specific settings and tools that are just for one codebase. It lets you create a hierarchy of environments if you so desire.
With this in place, I don’t have to know anything about a codebase in order to build it! I check out the code, run the universal
build command (which is set in every environment), and the codebase builds. No more asking around to find out if I should be using
gradle, or what arguments to pass to
Just last week, we open-sourced ZENv. Whether you’re starting a new project or you just want to get everybody on the same page, I heartily recommend forking the repo and setting something up that’s right for your team. ZENv allows massive customization, even including interactive setup and repository-specific configuration. The Quick Start guide and the wiki will give you all the information you need to create the sweetest development environment you can imagine.