DevOps Is Hard

My friend David and I recently started work on Portland Cafés. The idea was simple enough: we wanted to know which coffee shops were open and how far away they were.

I wouldn’t say the project was complete, but it was usable. Usable enough to go live. We decided that, in publishing our web app, we wanted to incorporate some sort of automated deployment process.

Roughly, this meant:

  1. We commit some changes on a feature or fix. These commits eventually end up in a “production” branch, master in our case.
  2. Changed files are transmitted to our server.
  3. The server builds the project from the new files.

On the surface, these steps don’t seem very complicated. The most obvious hole occurs between steps 1 and 2: something needs to respond to the post-commit hooks and deal with it. Several services exist to fill this hole. We looked at:

CircleCI was our first choice: their virtual machine runs your tests, deploying only when everything passes. That sounds awesome. After browsing the documentation and hooking it up to the repo, Dave and I quickly realized it was overkill. I wrote exactly one unit test. I don’t think Dave’s written any Ruby tests.

So, we settled on Deploy. Eight hours after pulling our hair out, we were set up.

This was my first experience setting up a legitimate deployment system. It was a nightmare. “Development operations” – the integration and automation portions, at least – requires such a broad and deep understanding of several technologies. We’re fairly focused: Dave’s a Ruby and JavaScript guy, I work in front-end land. All that hair-pulling is especially frustrating because it’s peripheral to our actual work. My time would be better spent designing a part of the app or coding up new features.

The initial setup was hell (I could write a whole article on lessons learned) but it will pay off. Automation is future time saved. Now, merely merging code results in deployment, which is easy and awesome.

If only we could stop Readme updates from firing off the whole thing.

Git’s Rebase

Atlassian has an excellent article on git’s rebase. When first learning git, I was told to avoid rebase like the plague. The article explains it with more nuance:

As an alternative to merging, you can rebase the feature branch onto master branch using the following commands:

git checkout feature
git rebase master

This moves the entire feature branch to begin on the tip of the master branch, effectively incorporating all of the new commits in master. But, instead of using a merge commit, rebasing re-writes the project history by creating brand new commits for each commit in the original branch.

Rebasing seems most useful for cleaning up local commits. Interactive rebasing looks like a very cool tool, too. Definitely worth looking in to. There’s also very good illustrations.

Announcing Capstone, a WordPress theme for Photographers

A screenshot of Capstone’s demo site

I’m very excited to announce Capstone, a WordPress theme for photographers. I designed and developed the theme over the last few months of 2014. It’s completely free and released under the GNU GPL v2 license.

The theme has a single page exhibiting the theme’s features, and the theme can be previewed on the demo site. Capstone’s source code is available on Github.

The theme isn’t in the official WordPress theme repository for a few technical reasons. As a previous blog post may have hinted, Capstone still offers seamless theme updates. The code for the update server is also available under the GNU license.

A paid “pro” version of Capstone is in the works. Stay tuned for updates!

Everyone JavaScripts

The ShopTalk Show podcast had Tom Dale on a few weeks ago. The entire episode is entertaining and informative, (especially with regards to Ember, but Mr. Dale’s rant about disabling JavaScript as a means of testing “progressive enhancement” around 42:00 was particularly poignant:

The web is a platform. There’s basically three major pillars that prop it up. There’s HTML, there’s CSS and there’s JavaScript. And for some reason, people decide that they’re going to disable JavaScript and decide that that is some arbitrary hoop that people have to jump through. We need to disable this part of the platform that, by the way, no one actually does in practice…The vast, vast majority of your users aren’t going around disabling JavaScript. Almost no one uses a browser that doesn't support JavaScript anymore…

Pick a date or pick support metrics. You don’t just get to say this entire piece of technology that drives the entire freaking web, we need to be able to rip it out and basically make our websites brain dead and they should continue to operate fully functionally.

I am partially guilty of this, usually as a manner of showcasing frivolous content-blocking scripts. But, Mr. Dale’s right: everyone runs JavaScript. Even so, the Ember team is working on server-side rendering for the page load, which is exciting news for application performance, especially on slower mobile devices.