official way to version manage espoCRM

[jamie]

Hi,

I am wondering if there is an official way to version manage code, data, and extensions.

We need to version manage this, as it's standard development practice for us to test changes properly

thanks

[jamie]

I would adore some guidance on this, the combo of extensions living in the file system and the database is making it difficult for me to do it how I am used to

[yuri]

I do not understand the question.

[jamie]

Good morning,

We’re using your excellent system to manage our customers, orders, and more. As a medium-sized company, we frequently receive requests for changes, which we prefer to develop on our local install, then push to a demo install for approval by the requester, and finally deploy to production. This is a fairly standard workflow.

Where I’m running into difficulties is with extensions. Since they modify the database, I’d prefer to keep them out of the repository and instead install them independently on each environment, much like how vendor files are normally handled. However, I’m wondering if there’s a better or recommended way to handle this.

thanks

[jamie]

ok after trying this for a day, extensions just are nowhere near self-contained enough to even think about leaving them out of the repo

would be great that if in the future they worked like vendor files and where totaly self contained

[yuri]

> extensions just are nowhere near self-contained enough

Could you explain what do you mean by this?

[yuri]

An extension is in just two separate folders for frontend and backend. There can be also an after-install, after-uninstall scripts, but these can be skipped. What exactly is not self contained? What is the main problem?

Adding extensions directories to gitignore should be suffice.

[jamie]

> extensions just are nowhere near self-contained enough

Could you explain what do you mean by this?

Yeah, thanks for asking. So, you know how vendor files are all contained within their own individual folders, with nothing existing outside of them? For me to have any hope of proper deployment and version control—while leaving out extensions—all of the extension’s files need to be contained inside a single folder.

For example, for the Mailchimp extension:

custom/espo/extensions/mailchimp

• layouts
• metadata
• migrations
• Every file related to the Mailchimp extension

Makes sense? Take a look at how vendors work for example

i fully accept that this ain't going to happen any time soon, though, just put the idea to you for maybe some time in the future, as it really would improve both extension development and enterprise-level deployment

cheers

[yuri]

There are only two folders as I mentioned above:

- custom/Espo/Modules/{Module}/
- client/custom/modules/{module-name}

Why not just one. Because it would require us to make the whole client directory copy to the publicly available directory.

You can add these folders to gitignore while whitelisting your own extension if you have one.

[yuri]

https://docs.espocrm.com/development/modules/#modules

[jamie]

There are only two folders as I mentioned above:

- custom/Espo/Modules/{Module}/
- client/custom/modules/{module-name}

Why not just one? Because it would require us to make a copy of the whole client directory and copy it to the publicly available directory.

You can add these folders to gitignore while whitelisting your own extension if you have one.

For some reason, I thought it was more, not quite as clean as a single folder, but manageable.

Though maybe in the future, having them managed through Composer would be amazing for me

Any advice on what to do when I remove a bunch of extensions from the repo and everything collapses due to random calls to dead extensions?

[yuri]

It can be that you have 3rd party extensions that does not follow the requirement or old extensions. All extensions should use only those two folders.

Managing via composer in not planned. The official recommended approach is not to use composer. I can't argue explaining why it's so, as I have a lot of work. We may consider implementing it has we received a huge investment that could allow us to spend resources on pandora-box things that are far from being primary.

> Any advice on what to do when I remove a bunch of extensions from the repo and everything collapses due to random calls to dead extensions?

Usually removing via CLI works: https://docs.espocrm.com/administrat...nds/#extension. If not, then one can remove those two folders first and then remove the extension via CLI.