The Symfony's Console Component (see http://symfony.com/doc/current/components/console/introduction.html) is great way of boosting productivity. It allows to easily create commands to perform various common tasks and invoke them from Shell (Bash/Zsh) with an argument auto-complete support and automatic help page generation for command usage out of the box.
What can be automated:
Direct execution of events
Right now events can be executed from command line using "php tools/run_event.php prefix-special:OnEventName secret-per-instance-hash". This can be automated into following command:
| No Format |
|---|
in-portal run-event prefix-special:OnEventName |
Unit creation
Unit concept is very powerful, but when it comes to creating new unit there is always place for human error. It turns out that we've created a lot of units over the years and you can automate most of the process to get developer right on track faster. Following command might help:
...
- create stub files for event handler, tag processor, unit config
- automatically determine used labels and DB table name based on prefix (will also ensure that prefix is named according to coding guidelines)
- automatically put correct Fields array definition based on database (no need to manually use "System Tools" and copy paste from there)
- with the help of additional command options fine-tune unit to be generated, e.g.:
- add change tracking fields, e.g. CreatedOn, UpdatedOn
- connect to Priority Helper
- make sub-item of other unit (automatic setup of foreign key and stuff)
- you name it
Database migration creation
Right now we have central project_upgrades.sql file where all database migrations are being listed. Because all migrations are in single file a unique revision number must be supplied by developer. Although there is validation in place that there are no duplicate revisions from time to time developers manage to create duplicates. This is a problem because such revisions will be silently ignored and only in time developer will be able figure out that in past particular revision wasn't executed.
If we switch to file-per-revision system (see Incorporate "upgrades.sql" into "project_upgrades.sql" [5.2.1-RC1] and Changing way, who upgrade scripts are stored) then with help of command from below it will be possible to automatically create unique files for each database migration (including PHP support):
...
Possibilities are limit-less.