I've reworked the init() function of Deployer.php to include a maybeAddCustomCommands() function, which checks for a DeployerCommands dir in the project root and, if any exist, integrate them with Deployer accordingly. Custom commands can either override stock Deployer commands or create new commands. These changes are 100% backwards-compatible, in that if no DeployerCommands dir is present, there are no changes to the current functionality.
One of the primary advantages of this restructure is the ability to customize the deployer.php templates being used, to include additional information or additional formats.
Here is a gist demonstrating an example implementation of a customized InitCommand.php file, which would be placed inside DeployerCommands/ at the project root. In this example file, I've customized
configure() -- customized the init command description
setDomain() -- new functionality to set project domain on initialization
guessHost() -- an example of a customized host-guessing procedure where our site includes a host.php file serving the hostname; this hostname can later be used in the deployer.php script
An alternative implementation of guessHost() could also integrate with a registrar's API, implement nslookup, just for a few examples.
For developers or engineering teams, the ability to override Deployer's stock commands and templates would make a huge improvement in standardizing implementation across projects, and allow them to script out many of the initial configuration steps for deployer.php which aren't quite covered by custom recipes.
I've reworked the
init()function ofDeployer.phpto include amaybeAddCustomCommands()function, which checks for aDeployerCommandsdir in the project root and, if any exist, integrate them with Deployer accordingly. Custom commands can either override stock Deployer commands or create new commands. These changes are 100% backwards-compatible, in that if noDeployerCommandsdir is present, there are no changes to the current functionality.One of the primary advantages of this restructure is the ability to customize the
deployer.phptemplates being used, to include additional information or additional formats.Here is a gist demonstrating an example implementation of a customized
InitCommand.phpfile, which would be placed insideDeployerCommands/at the project root. In this example file, I've customizedconfigure()-- customized theinitcommand descriptionsetDomain()-- new functionality to set project domain on initializationguessHost()-- an example of a customized host-guessing procedure where our site includes ahost.phpfile serving the hostname; this hostname can later be used in thedeployer.phpscriptAn alternative implementation of
guessHost()could also integrate with a registrar's API, implementnslookup, just for a few examples.For developers or engineering teams, the ability to override Deployer's stock commands and templates would make a huge improvement in standardizing implementation across projects, and allow them to script out many of the initial configuration steps for
deployer.phpwhich aren't quite covered by custom recipes.