I’m a DevOps and infrastructure leader who still does the work. I’ve built DevOps teams where there were none, moved AWS out of the console and into Terraform, and replaced releases built by hand with a pipeline where rolling back is one step.
Most of that has been under Magento and Adobe Commerce stores, which I’ve worked in since 2009. This is where I write about it: the infrastructure, the releases, and the tooling that proves a deploy worked before a customer finds out it didn’t.
Ever wanted to merge a few PRs in one go while getting your coffee? Three repositories, three approved pull requests, and nobody wants to click through three browser tabs on a Friday. One line: for pr in "bluetir 6" "kapelos 1" "solander 4"; do gh pr merge "${pr#* }" -R "kingletas/${pr% *}" --merge --delete-branch || print "left: $pr"; done Hit enter, go get the coffee. When you’re back, either everything merged, or the loop tells you exactly what it left behind. ...
We keep one plain text file that lists every repository we gate, one path per line. Then we needed a new hook in all of them. You don’t need a full programming language, or to do it by hand. Plain ol’ bash does it in one line: while read -r r; do install-hooks "$r"; done < <(grep -vE '^[[:space:]]*(#|$)' repos.txt | sed "s|\$HOME|$HOME|; s|^~|$HOME|") install-hooks stands in for whatever installs your hook. Ours is our commit gate’s own install command. ...
We wanted to know what a maintenance window really costs a Magento store, against the alternative. Our deploy playbook takes one whenever a release has database work to do: every web server switches to the new code at once, the store shows its maintenance page while setup:upgrade runs, and then it comes back. The alternative is harder than it sounds. A rolling release, a canary or a zero-downtime deploy all need two versions of the code serving from one database at the same time, and Magento pushes back on that in three layers. It refuses pages when a module’s version doesn’t match the database. It refuses requests when the deployed configuration doesn’t match the imported one. And nothing at all protects a query that meets a schema it doesn’t match. A flag, deployment/blue_green/enabled, switches off the first two. Nothing switches off the third. ...
The last time I looked for a job was in 2018, that feels like a millennium ago. A full dark age ago. Things have changed a lot. AI and machine learning is no longer a nascent industry but one completely embedded in our lives. It was a massive shock for me to look for a job and find that the traditional way was… not the recommended way anymore. Yes, you can still count on your connections but getting through the door is more complicated than ever before. ...
On 7 September we went looking at customer/section/load on a stock Magento 2.4.8 store with the sample data. It’s the request that fills in everything a cached page can’t know about you: your name, your cart count, your messages. It can never be cached, so every call boots the whole application. One response was 61,194 bytes. About 59 KB of that was directory-data: every country and every region the store knows. The same list for every visitor on the planet, travelling through the one channel in Magento that exists because responses can’t be shared. ...
Nine days after the Varnish post, in July 2012, I wrote PHP Offloading… Nginx helps so much!. It explains why nginx beats Apache for Magento (“we are all about performance aren’t we?”), then hands over an nginx server block and a PHP-FPM pool with “of course suggestions are welcome”. Fourteen years on, here are mine. The pool starts like this: pm = dynamic pm.max_children = 50 pm.start_servers = 5 pm.min_spare_servers = 5 pm.max_spare_servers = 50 pm.max_requests = 500 Fifty. The post never says where 50 came from, and that one number decides whether the box runs flat out or falls over. So this is mostly about how to pick it, with two things the rest of that config got quietly wrong along the way. ...
The PHP-FPM reread ended on a promise. The same July 2012 post, PHP Offloading… Nginx helps so much!, hands over an nginx server block, and one location in it has a problem that has nothing to do with performance: location ~ .php$ { ## Execute PHP scripts if (!-e $request_filename) { rewrite / /index.php last; } ## Catch 404s that try_files miss ... fastcgi_pass unix:/var/run/php-fpm/php-fpm.sock; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; ... } “Execute PHP scripts” is exactly what it does. Any request ending in .php goes to PHP-FPM, and PHP-FPM runs whatever file nginx names. Nobody asks whether that file was ever meant to be a script. So if somebody can get a .php file into a folder the web server serves, through an avatar upload, an import, a product image field that checks the extension a bit too loosely, that file runs. ...
In July 2012 I wrote a post called Varnish implementation hints and good to know. It opens with “Sharing knowledge is always a good idea,” and then shares, in order: a set of bash aliases that switch Varnish on and off with iptables, a header that tells PHP whether Varnish is in front, a cookie-stripping regex, a one-line purge, and what it calls “a favorite of mine”, a function that walks every URL in the sitemap so you can clear them all. ...
On 7 September we wrote a script to bring every repository on our GitHub account to the same settings: branch protection, secret scanning, the files a public repository should have. It had a dry-run flag. Run with it, the script said: every repository in scope already conforms It had checked none of them. getopts stops at the first word The script took a subcommand and then flags: apply -n. It parsed the flags with getopts, bash’s built-in option parser, which reads arguments from the front and stops at the first one that doesn’t start with a dash. The first argument was apply. So getopts stopped there and never saw -n. ...
“are these tasks still running?” I asked that on 2 September, about two background jobs Claude had started, which had been sitting at “Running” for 94 minutes. They were waiting for a Flatpak SDK to finish installing. It had finished at about the four-minute mark. Nothing had failed. They were waiting for themselves Both loops tested for the install with pgrep -f "flatpak install", and were written to stop once nothing matched. pgrep -f searches the whole command line of every process. It leaves itself out of the results, but not the shell that called it, and that shell’s command line held the entire loop. So each loop found itself, and each found the other. They were waiting for their own exit. ...