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!
Tag: Continuous Delivery
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!
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? Run
git 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: