Hi pgr, thanks for your reply.
Yes I saw symfony migrations, but I do not want to “go against” the legacy behavior. There is already the builder to configure properly verything and code to manage schema migrations and so on (through module loader), I don’t wand to add an extra layer here but only have a smoother gitlab workflow.
Of course, I’ve also look for the symfony console first.
So, I did some debug,and the situation is currently:
- SQL scheme migrations are managed by the
ModuleInstaller class, and especially the install_custom_fields method called by install().
- There is no console command to call this method, only GUI available. So you have to deploy packages manually when you add/remove some fields in the SQL database (or develop your own command, I didn’t look this right now). Consequence: no full CI/CD gitlab pipeline possible… (but continue to read, there are some good news bellow
)
For the git strategy, there are 2 cases that do not involves the same process:
- you do “SQL modifications or related to” (fields, layouts, relationships, etc…)
- you do not do “SQL modifications or related to”: hooks, controllers, etc…
No SQL modifs
This will probably be more than 99% of your code changes. You can track your changes, and deploy it like you want. It’s just a file like in another Web project. CI/CD is possible as usual! 
SQL modifs
You want to modify things related to fields, layouts, relationships, vardefs and metadata will be updated in the process.
I’ve found 2 solutions that seems to work:
Disclaimer: because I’m a beginner in suiteCRM, I do not envisage to edit filed that th GUI can do for me (and without errors). It could change in the future.
Studio strategy
Developer’s computer
After have created your package & module with the package builder, you do personnalization with studio only. You track 2 things:
public/legacy/custom/modules/<your-module>: this is the diff generated by studio. It allows for others member of the team to review the changes, and if they checkout the merge request they would be able to get studio in the same state than yourspublic/legacy/custom/modulebuilder/packages: well, you want also to track the zip file of the changes when you publish it.
Server
You have to be careful with update because there is potentially 2 step:
- push your new files (non SQL related) to the server
- don’t forget to install the new module upgrade if new SQL fields are involved
- In the module loader, you have 1 module diff per update
At this point my question is: how do peoples who sell plugins to their customers? When they ship an upgrade, they need to have everything encapsulate in the same zip files. How the zip file is built? Via module builder?
Module Builder strategy
Developer’s computer
After have created your package & module with the package builder, you do further personnalization still with the module builder. You never use Studio and you track 2 things:
public/legacy/modules/<your-module>: the code of the modulepublic/legacy/custom/modulebuilder/: this is the code generated by the builder + you want also to track the zip file of the module when you publish it.
Server
You have to be careful with update because there is potentially 2 step:
- push your new files (non SQL related) to the server
- don’t forget to install the new package version if new SQL fields are involved
- SQL schema migrations are managed if you apply a rebuild & repair at this point
- In the module loader, you have 1 full package per modification
Based on the previous question, what is stategy that modules’s developer ususally do? Do they ship a new module version that erase completely the old one?
And I’m not sure about the best strategy to follow. Should we use studio for updates, or is it also OK to use module builder?
I’ve found a @pgr answer here Code changed after deploy in module builder - #3 by pgr but I’m not sure I have a clear view about pros/cons of each solution.
Thanks
cpol0
