Steve Grunwell

Open-source contributor, speaker, and coffee snob

Tag: Continuous Integration

Looking out from the Smithsonian Natural Science museum on a foggy day

My First Workshop @ php[world] 2019!

It’s no secret that I’m a big fan of php[world]: php[world] 2014 was my first big speaking engagement, and I’ve spoken at the 2016 and 2018 editions of the conference (and attended in 2017). That’s why I’m thrilled to announce that I’ll be returning to Washington, D.C. this October for php[world] 2019!

Continue reading→

"Free Delivery" written in a script font on a restaurant window

Continuous Integration and Delivery @ Cincy Deliver

I recently subscribed to Karl Hughes’ excellent CFP Land newsletter, which has exposed me to a ton of new conference speaking opportunities. Among them, Cincy Deliver (previously Cincy.Develop() and Cincinnati Day of Agile) just a couple hours south!

On a whim, I submitted a few talks, and I’m proud to announce that I’ll be giving a brand new talk, Build and Release Confidently with Continuous Integration and Delivery, at Cincy Deliver 2019!

Continue reading→

An exposed lightbulb sitting atop a pile of books

Atomic Deployments from Scratch

Years ago, a mentor of mine introduced me to a Ruby-based server automation tool called Capistrano, and I immediately fell in love. Ready to deploy a new release? Rungit push && cap production deploy, then you’re done. Even better, Capistrano introduced me to what’s colloquially known as “atomic deployments” — checking out a full copy of the codebase and using symlinks to point to the new release for a zero-downtime deployment — which has since been my gold standard for deployment methods.

I continued to use Capistrano for a few years, until I started working on projects (and teams) large enough to justify a proper continuous delivery (CD) tool. Suddenly, building the application locally and pushing up with Capistrano became more complicated; at the same time, services like DeployBot began offering atomic deployments right out of the box, so it was easy to get up and running.

What about services that don’t offer atomic deployments as a default? I recently deployed a Laravel application via Codeship, where atomic deployments to a VPS becomes more complicated; here’s how I approached it:

Continue reading→

My Laravel Tests were Failing because of my App URL

In my role as Senior Software Engineer at Liquid Web, I’ve gotten to get back to my roots of not only doing WordPress, which has been great. In particular, I’m getting back into Laravel, getting to build real web applications in an environment that makes testing a breeze (aside: if you haven’t checked out Adam Wathan’s Test Driven Laravel course, I cannot recommend it enough!).

I ran into an interesting problem today, however, when I updated the APP_URL variable in my .env file: running my [previously 100% green] test suite, I was getting random errors and failures within my feature tests that I hadn’t been seeing before. Controller actions weren’t responding properly, model relationships weren’t always behaving, and redirects following actions were hit-or-miss.

Continue reading→

Be excellent to each other.