Deploy and RUN!

I don’t remember how it started. At some point I realized that I was deploying some new code right before going on vacation, leaving for the weekend or… something. The first time I mentioned it on twitter was in March 2015…

Is this confidence in our setup? Is this just stupid? It brings me great delight. I approach it with glee. I’ve even gotten my co-worker S. on board; today our co-worker R. was horrified to realize she’ll be running a couple of big content launches soon, and going on vacation immediately after each one. S. and I just said, “Deploy and run!! YES!!!”

BUT you know the thing is, when you deploy all the time, almost daily, both code and content… it’s going to happen. You can’t hold off on deploying all the time. Most things can be rolled back. Nothing reaches the live site before it has been tested and used by multiple people. When deploying constantly, deploys tend to be small, often with low overall impact to the site. [1]

The other day at work there were signs at both of the main building entrances. The signs were to thank the people involved in a large, multi-year effort to launch a new application. It’s an important application, dealing with customer data, and a lot of people worked on it. They deserved hearty thanks and recognition.

When you deploy and launch constantly, though, there are never signs in the lobby. Each launch flies under everyone’s radar. Deploy and run is fun because it’s bad, long years of IT experience say we’re not supposed to do stuff like that… but with constant small deploys we’ve achieved pretty good stability in the site, and even though it feels like we’re breaking the rules, it’s usually pretty safe.

Today I’m deploying some content using a new process and some new scripts I’ve been writing. It’s a little more complicated than a normal content deploy (and deserves its own blog post). I’ll be touching about 75 pages in one way or another. I’ll be running wp-cli directly on the live site, which gives me pause. Then I’ll be gone for a week, and another critical team member will be out for a few days as well. As deploy-and-runs go, it’s a big one…

Whee! Right?


[1] What would be really perfect is if we used feature flags…

True confession: I might kinda like platform

After seeing a talk given by Yvette Pasqua on Tackling technical debt at scale, I started dividing our developer work into two areas: product, and platform.

Product is almost always plugin development or theme development.

Platform encompasses the underpinnings: the git to Bamboo code deployment pipeline, the mySQL databases, configuration that is put in the wp-config.php, and tools needed to move content from stage to live. Dark launch is part of platform, and so is a new, related process that I’ve been working on lately that I’m calling content branching.

The tools to support content branching are all written in shell scripts with WP-CLI commands embedded in the scripts. On this project I’ve definitely expanded my shell scripting skills, and I find that to be quite fun.

I have long thought of myself as an applications developer first and foremost, with the ‘ops’ part of my skills firmly placed in the past, from before I became what I really wanted to be: someone who makes things.

In fact, it has only been in recent years that I’ve realized I actually do get great joy from solving problems, one of the defining characteristics of good ops people. I long conceived of myself as a creative who got great satisfaction from making visible things and happened to be able to develop the technical skills needed to express myself in code. I shied away from an identity as a problem solver – after all, I was so bad at math in school, how could I love solving problems?

I stopped trying to deny that about myself a while ago, but still I have complained many times about being drawn away from product work by the constant need to build out and shore up the platform. Maybe because product is where we make the visible things. Platform is all invisible, there’s nothing pretty to look at except a bunch of green success messages from WP-CLI (and those are never on public view the way a web site is). The great joy of platform work is in solving the problems. Oh, so many problems.

green success messages
Trust me, this is pretty awesome. Many problems were solved to bring us these success messages.

I think content dark launch was the turning point for me. My source of distress is no longer that I never get to work on product, it’s that platform’s needs are so overwhelming that I found myself blurting out in a recent meeting I am drowning! [1] This is, I can now see, a personal evolution. As an enterprise CMS WordPress is so primitive that there’s lots of room for new ideas and novel solutions to certain kinds of problems. Content dark launch is not very well-trodden territory in the world of WordPress writing and WordCamp talks and it is thrilling to bring something new(ish) to that world.

Day to day as I write my scripts for content branching, I feel happy. I love solving the little problems at each step, and I get a lot of satisfaction out of solving the larger problem. So I must confess to myself and the world: I like platform. I might even love it a little.


[1] It’s okay, I’m better now.


Content Dark Launch

In March 2017 I gave a talk at WordCamp Raleigh on content dark launch, a technique that has saved us many hours of stress when launching new sections of content on our WordPress-based intranet site.

If video is not your speed, I’ve written up most of the talk below as well.


Continue reading “Content Dark Launch”

My peculiar trajectory as a PHP developer

“Step into the confessional,” my physical therapist always used to say before asking me how well I’d cared for myself since my last visit.

I didn’t talk to many new people at WordCamp US last year, but there’s one conversation that stands out in my mind: I spoke for a while with Alain Schlesser about development topics. He told me about his novel approach to an enterprise WordPress project, and, among other things, he encouraged me to get outside of the WordPress bubble as a developer, and get in touch with the larger PHP developer world.

His talk describing that very project just posted to today and that reminded me of our hallway discussion.

Here’s my confession: the truth is that as a PHP developer, I’ve always been very isolated, and despite years of working with PHP, I’ve never been in touch with the larger PHP community. I didn’t even realize I was isolated until my team got serious about WordPress a couple of years ago. It’s kind of shameful, but it didn’t occur to me that there might be PHP conferences, online discussions, or other ways of being in touch with PHP developers. Since I’ve been actively developing in PHP since 1999, this is really kind of ridiculous, especially now that I can see what a large world there is for PHP.

Continue reading “My peculiar trajectory as a PHP developer”