Steve Grunwell

Open-source contributor, speaker, and electronics tinkerer

Tag: Continuous Integration

An ornate, metal gate overlooking a body of water

What are Continuous Integration & Delivery (CI/CD)?

Lately, I’ve been thinking a lot about helping smaller teams—especially those working with “legacy applications”—modernize their workflows. Working for a Fortune 500 company on an “enterprise-scale” application every day can cause you to take things like Continuous Integration and Delivery (CI/CD) for granted.

With that in mind, I’m going to try to turn my attention to simplifying some of these concepts. If you’ve ever been told “you should be using continuous integration” and been left wondering “okay, but how?” this post is for you!

Continue reading→

Cloud Gate (a.k.a. "The Bean"), surrounded by tourists in Chicago, IL.

Continuous Integration and Delivery @ php[tek] 2023

It’s been a long time since my last in-person conference: php[tek] 2020 was cancelled due to the pandemic, and the live conference circuit has been sparse since COVID-19 rocked the world. As a result, my few speaking engagements have been strictly virtual since early 2020.

To be perfectly honest, it has been a total let-down. A pandemic sucks on its own, but seeing so many small conferences going under—it’s been painful to watch. My friends Heather and Eli at One for All Events have seemingly had to shutter their company, and their flagship events, php[tek] and php[world], haven’t happened since 2019.

php[architect], the organization that run those conferences, is now under new ownership: John Congdon and Eric Van Johnson of DiegoDev acquired the company in October 2021. Now, they’re bringing back php[tek] for the first time in three years, and I’m thrilled to be a part of it!

Continue reading→

A series of pipes and gauges along a wall

Travis CI for WordPress Plugins

If you’ve spent much time on GitHub, you’ve probably come across repositories with green badges that look like this: Build: Passing

A lot of repositories will have these badges/shields, as they indicate that the last run of the Continuous Integration (CI) pipeline for this repository “passed” (e.g. everything is working as expected).

Now, Continuous Integration can mean a lot of things: maybe the project has a wealth of well-written tests that are all passing, or the simply that coding standards are all up-to-par. No matter the coverage level, this green badge indicates to potential users of your code that it satisfies the quality checks you’ve put in place.

Better yet, once we have a Continuous Integration pipeline in place, we can make it a prerequisite for pull requests to be merged. If you’re tired of PRs that don’t respect your project’s coding standards, ignore PHP compatibility rules, or otherwise produce lots of overhead, automating the high-level testing can save you lots of time.

Continue reading→

Ohio Laravel logo

Continuous Integration & Delivery @ Ohio Laravel

My local Laravel usergroup, Ohio Laravel, is a monthly opportunity to talk tech with some of the brightest PHP developers in Columbus.

At a recent meeting, somebody boasted how easy it is to “just zip up a PHP application and drop it on a server.”

“Better yet, SSH into the server, do a git pull , then run composer install!”, someone else chimed in.

As the resident testing advocate and pipeline geek, I was quick to chime in: “wait, what? Are you really still doing an SSH + git pull combo in 2019?”.

Long story short, I’ve been invited to talk about Continuous Integration and Delivery at the November Ohio Laravel meetup.

Continue reading→

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.