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 had 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.

[jamie]

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.

I think it was just late in the day and I was tired of dealing with it, so I ended up adding everything back into the repo — and it worked. I did try the CLI approach, but I couldn’t get an old version of the Sales Pack to uninstall, which was causing a 500 error on the web interface.

For now, I’m fine with keeping them in our repo, especially since I already have a composer.json file to manage the vendors. Sometimes it feels like a bit of back and forth to get across exactly what I want, but knowing the reasoning behind your approach definitely helps me work around things.

I’m really glad you’ve received investment — you absolutely deserve it. The application is fantastic, with so many powerful tools for advanced front-end users.

Maybe now’s a good time to poll your users about which features they’d like to see. From my perspective as a developer implementing your app, I’d love to see more tools for managing deployments in a modern way — things like Docker/git integration, and splitting up the data/config.php file to remove version numbers and cache timestamps.

And perhaps having a dedicated support person could give you more time to focus on coding, while still keeping users supported.

Remember, hope also came out of Pandora’s box.

Have a great weekend — and if you’re ever in Manchester, we’ve got a couple of beers waiting for you!

[yuri]

We haven't received investment. It was my typo.

I don't believe that the polling is good for the product now. Too little users who would vote. And they are already users. If the product needs to attract more users, the polling won't represent those potential users. We have enough feedback to understand points that needs to be improved. We have much more users than those who participate of the forum. What users ask and what actually brings us revenue are often not the same.

> see more tools for managing deployments in a modern way — things like Docker/git integration

It's too vague. We'd appreciate more specific requests. The docker has been already there for long. Maybe not an ideal solution, but I'm not sure if it's possible to have an ideal docker solution for PHP apps, PHP not ideal for dockerization.

I don't understand what is git integration. BTW I don't consider deploying with GIT as a good/modern approach.

The product is not intended to be forked and developed separately. It's not a framework product. I'd view it as an already compiled product. One who needs to customize it, can utilize the extension development framework. There are numerous ways to deploy it. We don't suggest any approach. If anybody from the community could share, I'd appreciate it.

[jamie]

Oh, damn—and here I was hoping someone had finally realized just how amazing Espo really is!

I’d suggest running a poll directly inside Espo, maybe pushed out through an update. You’re right: not many people hang out here, and those who do usually represent a small slice of the user base—often the more technical crowd or those running into issues.

Espo, as an application, is definitely enterprise-grade in terms of capability. But for most enterprises to take it seriously, it needs to fit cleanly into a deployment pipeline. A standalone app can feel too fragile—any breakage by a “well-meaning user” could easily cripple a large organization. That said, it does actually run very well in its current deployment model—I’ve just had to do a bit of fiddling with extensions to get everything working smoothly.

When you say “modern approach,” what do you have in mind?

[yuri]

I meant pushing GIT repo to the production as not the best approach.

Espo hardly differs from other PHP apps. There are numerous ways to craft a deployment process for it. As we are the vendor and our own deploy is very specific that won't work for others, we can't recommend any specific approach. There are better specialist out there who could craft a good deployment pipeline than I. Hope the community will eventually share good solutions.

[jamie]

Yeah, your deployment will be quite different from ours. It seems unlikely that folks will comment in here. Is there a better place/way to post this?

Hope you had a great weekend