(Also known as “why doesn’t Capistrano pick up my changes???”)
One of the cool things about Capistrano is that you don’t even have to put your Capistrano files into your app repo. You can put the Capfile and config/deploy.rb and so on in a different repo, or its own repo, or no repo or whatever.
One of the really infuriating things about Capistrano is that it’s designed to allow you to do that. See the bottom of this post for a quick workaround, or just keep reading.
A few weeks ago, I was hacking away on prototype software for my new class. I was doing that horrible thing where you make a few changes, hit “rebuild” and wait for five minutes to find out if you fixed the problem. And I realized something surprisingly awesome about configuring servers.
Deployment turned into high-end development while we weren’t looking.
The best tools for configuring your server, Chef and Puppet, now describe themselves in terms of idempotence and declarative programming — they’re using the same concepts as Big Data tools, functional languages and other theory-heavy development.
And those “best tools” aren’t in a lab or a research paper somewhere. Silicon Valley already uses them and the rest of the world will soon. Puppet and Chef are extremely common – my last four years of workplaces all used them. These tools just work better than the provisioning tools before them.
Like most “best tools” you don’t know much about, they’re a bit young and raw. “Cutting edge”, you might say. “Bleeding edge” wouldn’t be far off either. They’re clearly still growing new features — and even whole new areas of functionality.
Welcome to the new world where “deployment” is a new, interesting, involved, painful kind of development. Just like web development was fifteen years ago, and Big Data was five years ago (or now, depending who you ask.)
It’s easy to find posts about how to set up a Rails server manually. There are a ton of them out there.
It’s also easy to put off setting up Chef until later on. After all, how often are you going to set up a server? Do it manually, then automate when you need to, right? That’s the tradeoff.
Why would you use Chef before you had to?
That’s a good question. Let’s talk about that.
Chef and Vagrant for Test Servers
If you use Vagrant you can easily put together a test server. Unfortunately, if you just type a bunch of commands into your Vagrant server, you’re always at the mercy of the VM going away.
Or you can use Chef. And then you can always get a clean new VM matching your server pretty well.
With a test server, you can answer questions like, “will this work if I type it on the production server?” And you can do it without crashing production. So that’s kind of cool.
An ambitious young programmer asked me recently, “how do I balance learning new specialties with producing good results?” It’s a great question, and a hard balancing act.
It took me too many years to learn this. I hope the rest of you learn it much faster than I did.
A Tale I Will Thee Tell
If you find a project that your management considers highly productive that uses a new-to-you technology, then you can learn and be productive. That’s a best-case scenario, but it happens semi-often.
Watch for it, just in case.
But if one of those was obvious, you wouldn’t have asked me. As Michael Church writes, those opportunities are often reserved for the programmers who play the politics game best — if you do well, many of those will mysteriously open up to you.
But let’s say you can’t get that, not yet.
Your Goal: Be Like Old Google
Next best is to have a perceived-as-high-value activity that doesn’t take all of your time. This is much, much easier than it sounds. If you can do that, you can declare your own old-Google-style 20% time, especially if you don’t declare it out loud. The keys to being perceived as highly productive are, roughly:
1) Be sure to ask your managers, and occasionally their managers, what the company values. Patrick McKenzie’s article talks about doing this during your interview — and yes, do that, but don’t stop doing it once you work there.
Also, ask business-critical groups (e.g. Sales, Marketing) and politically powerful groups (e.g. Product, Finance) what they get from Engineering. You ask because they remember the stuff they value and forget the stuff they don’t. So their answers will not be a good match for what Engineering thinks that Engineering gives them. Their answer tells you what you want to be working on. Those are projects they consider valuable and noteworthy. If you do a good job on projects like that, they will remember you personally. At least, they will if you do steps 3 and 4 correctly.
You’re going to need to take control of your own deployment. Heroku, for instance, isn’t going to handle that well.
But first, here’s a little parable about Bob (who is, um, totally not an alias for my early mistakes… Probably.)
The Parable About Bob
Bob was an old-time C programmer. When he built C programs in his spare time, nobody ever saw them. You can give people source code, but usually they can’t use it in that world. And building an installer is horrible, especially if you have any friends with a different OS than you use. That used to happen, back in the day.
Ruby on Rails was awesome and Bob loved it. You could put something on a server and then your friends could use it. How cool is that?
When I create and promote fun content, I get more subscribers, more goodwill and more engagement.
When I ask my audience to buy things, or even sit through being asked to buy things, I lose those things, by and large.
So this product trek is kind of an alternation — "power up" my audience by giving good things, and then turn that into "hey guys, buy my class" or "please fill out this survey" or whatever I’m asking of them.
Unrelatedly: I don’t feel like a person who sells products when I have successes. I feel like a person who sells products when I’m mid-slog and I know exactly what part comes next.