A single command-line instrument promises to end the tyranny of midnight deployments, broken symlinks, and half-finished release scripts — forever.
By Our Shipping Correspondent · Filed from /var/www
In an age when software moves faster than the presses that once set this very page, a modest PHP utility has quietly become the standard-bearer for reliable releases the world over. Deployer, as it is known to the tens of thousands of engineers who trust it nightly, has earned its place beside the text editor and the terminal.
The philosophy is a simple one, yet often forgotten in our era of byzantine pipelines: a deployment should be atomic, reversible, and — above all else — boring. A release ought to happen while the coffee is still warm, leaving the engineer free to attend to matters more worthy of their attention.
Out of the box, Deployer ships with recipes for every framework of consequence. Laravel, Symfony, WordPress, Drupal, Magento, and a parade of others are supported without ceremony. Servers are provisioned. Releases are linked atomically. Rollbacks, when required, require only a single word.
“Deploy and rollback in seconds,” reads the motto stamped upon its masthead. A generation of site-reliability engineers will attest that it keeps its word.
The Features Desk
Exclusive · Engineering
Zero Downtime, Guaranteed: Inside the Atomic Symlink Switch
A time-honoured technique, executed with military precision. Users see no seam between the old release and the new.
Long-suffering operations teams have for decades lived in terror of the dreaded “mid-deploy 500.” Deployer's atomic release model lays that terror to rest. Each deployment lands in its own timestamped directory, verified in isolation, and only then promoted to the live current symlink in a single filesystem operation.
Should a catastrophe be discovered in the wild — a bad query, an absent environment variable, a forgotten migration — the engineer need only issue dep rollback. The previous release, still resident on disk, is reinstated in a single heartbeat.
Observers describe the experience as “uneventful,” which is, in this trade, the highest possible praise.
Technology
Parallel Dispatch: Ten Servers, One Command
Sequential deployment, long the scourge of the fleet, has met its match at last.
Where once a release to a dozen hosts meant a dozen anxious waits, Deployer now dispatches to the whole fleet in parallel. SSH connections are multiplexed, tasks are scheduled, and logs stream back in orderly columns.
Engineers who have recently migrated from hand-rolled shell scripts report recovering entire evenings of their lives. “It is as if someone gave us back our Thursdays,” one such engineer told this publication.
The parallelism is configurable, naturally, for the pedant who insists on staggered rollouts.
Dispatch · Infrastructure
One Command Provisions a Server; Readers Astonished
Firewalls, PHP, databases, and HTTPS certificates — summoned without ritual or sacrifice.
The dep provision command, introduced in recent editions, has been hailed as nothing short of miraculous by those weary of hand-editing nginx configurations in the small hours.
A bare Ubuntu host becomes, in minutes, a production-ready web server. Let's Encrypt is wired. The firewall is closed, save for the necessary ports. The database awaits its first migration. The engineer, meanwhile, is nowhere to be found — likely, one hopes, asleep.
Opinion & Editorial
“A deployment tool ought to be the least interesting part of your week. When it is otherwise, something has gone terribly wrong.”— The Editors
From the Editor
In Praise of Boring Deployments
We are told, at every conference and in every blog post, that our deployment pipelines ought to be exciting. We are told to embrace novelty, to pile orchestrator upon orchestrator, to maintain a YAML file the length of a Tolstoy novel.
We dissent. A deployment tool, in our view, should be the dullest instrument in the kit. It should do its job, and then kindly get out of the way. The engineer's Saturday belongs to the engineer — not to an errant build step on a forgotten CI runner.
Deployer, refreshingly, is of this school. It is fast, it is deterministic, and it is — we say this with admiration — utterly without drama.
Around the Wire
Framework Desk
Recipes for Every Flavour of PHP
The Deployer standard library now ships with recipes for Laravel, Symfony, WordPress, Drupal, Magento, Shopware, CakePHP, Yii, CodeIgniter, TYPO3, Contao, Sulu, and more besides.
Each recipe encodes the wisdom of a community: which directories must be shared, which files writable, which caches cleared, and in what precise order. The engineer inherits this wisdom for the price of a single require.
Readers are reminded: friends do not let friends deploy on Fridays.
Today's Puzzle
1
2
3
4
5
6
1ATo ship, atomically.
Across
1. To ship, atomically.
3. Undoing yesterday's release.
5. The language we love.
6. A server where the release lands.
Down
2. Git ___ request.
4. The Bourne-Again shell.
Letter to the Editor
Sir,
I wish to record my gratitude. Having spent the greater part of the previous decade hand-crafting deployment scripts of ever-increasing complexity, I have lately converted to Deployer and find my weekends returned to me intact.
— A Grateful Engineer, Berlin
The How-To Pages
Instructional
A Three-Step Programme for the Aspiring Deployer
First, acquire the instrument itself. A single curl is sufficient to procure the latest edition in PHAR form, suitable for deposit anywhere upon the PATH.
Second, author a deploy.php of modest proportion — the framework recipe shall supply the remainder. Declare thy repository, thy hosts, and thy shared files. Save, and commit.
Third, invoke dep deploy and observe. Should any step fail, the prior release shall remain untouched and thy production site undisturbed.