Currently you can use the deploy system to automatically create all Fusio resources i.e. operstiona, actions, schemas etc. from a GIT repository. Therefor you only need to describe those resources at .yaml files and then you can use the php bin/fusio deploy command to push those changes to your Fusio instance. This has the great advantage that you can put your complete Fusio configuration under version control and you can easily create a new Fusio instance with the same settings.
The deploy system currently does not updates source files i.e. if your operation references a custom action class in the src/ folder Fusio will not deploy this class from the src folder instead it will only create the operation. If you deploy this to a remote server it will result in an error since the action class does not exist on the server. It would be great if the deploy command would also provide a way to send all src/ files (and probably also the resources/container.php) to a remote Fusio instance. Maybe we can also think about the composer.json and vendor/ dependencies.
Currently you can use the deploy system to automatically create all Fusio resources i.e. operstiona, actions, schemas etc. from a GIT repository. Therefor you only need to describe those resources at
.yamlfiles and then you can use thephp bin/fusio deploycommand to push those changes to your Fusio instance. This has the great advantage that you can put your complete Fusio configuration under version control and you can easily create a new Fusio instance with the same settings.The deploy system currently does not updates source files i.e. if your operation references a custom action class in the
src/folder Fusio will not deploy this class from thesrcfolder instead it will only create the operation. If you deploy this to a remote server it will result in an error since the action class does not exist on the server. It would be great if the deploy command would also provide a way to send allsrc/files (and probably also theresources/container.php) to a remote Fusio instance. Maybe we can also think about thecomposer.jsonandvendor/dependencies.