Deploy to Heroku?

[bandtank]

Has anyone deployed EspoCRM to Heroku? I am thinking about buying the advanced pack and deploying my site to Heroku, but I'm not sure if that will work. I'm aware that cron may be an issue, but I'm willing to trigger cron.php externally through a service like EasyCron.

Part of the draw to Heroku is the git integration. I would like to continue using git branches for development and production servers, which is incredibly easy on Heroku. I plan to heavily customize EspoCRM, which is why I'm asking these questions. I would very much prefer not to deal with managing my own EC2 deployment servers.

I'm open to other options if you have suggestions that are better than my current plan for any reason. Any help would be greatly appreciated.

[wtconseil]

Hi

i have similiar point of interests
and opened these topics

http://forum.espocrm.com/forum/installation-and-upgrade-help/25254-deploy-espocrm-inside-docker-container-immutable-kubernetes-cluster

http://forum.espocrm.com/forum/feature-requests/23705-upload-all-files-to-an-object-store

Today, with "zip upgrade" procedure.. i didn't find a good way to do my rolling upgrade easily
and i don't know how to sync my database schema to have a lifecycle easily between dev -> staging -> production environment

[bandtank]

Thanks for your response. I think we can work together to figure this out. I'm going to try a bunch of test releases to Heroku this weekend to see how it goes. Basically, here's my plan:

1) Setup a git branch for development and another branch for production
2) Setup Heroku with two environments: a production server and a development server
3) Setup Heroku to automatically deploy development branch commits and manually deploy production commits to the respective servers
4) Setup a MySQL database instance on Amazon RDS with two schemas: development and production. The development and production servers will point to different databases.

That's a pretty typical configuration, so I'm interested to see how well it works with Espo. When I do things like this, I make an automatic deployment and population of a database specifically for the development environment. This becomes more complicated when file upload tests need to work, but it's all possible with the right test infrastructure. We can develop this together if you're interested. I definitely can't use Espo until the file upload situation is resolved, so I am very motivated to find a solution to HA deployments and remote object stores.

One way to deal with files is to upload them to a public API for S3, Dropbox, or something similar. I think that should be relatively easy to do, but natural support would be way better.

[bandtank]

It doesn't seem like running EspoCRM in an HA environment is going to be easy and it may not work at all, actually. It was not built to work with any type of deployment process as far as I can tell because it requires local files to be installed to tell the app it has been installed. That's a really bad behavior for an HA application and I don't see a way around it right now. This kind of app should never install itself. It should be built to go once the database credentials are correct, which should be specified in .env file so it can run in multiple environments without storing credentials in the repository.

Maybe I missed something and I hope I did. I'm thinking about how I can achieve this type of deployment in the mean time.

[bandtank]

I made a fresh install of the whole application and database. Here's what changed after running the install wizard:

new file: data/config.php
new file: data/preferences/1.json

That's helpful to know because now the application can be deployed as long as the deployment process copies both of those files onto the host.

[bandtank]

Ok, so now I realize what 1.json really means - it was the preference file for the administrator user. I didn't realize Espo was going to try to save every preference file locally instead of in the database. This app can't be scaled at all without a major overhaul unless I'm missing something major about how the software saves resources locally to each server, so I'm looking at other forum software (for other reasons I won't mention here as well...). The rest of the app seems fine for the most part except for the extremely sparse documentation, but not being able to scale up is a showstopper. You'd only be able to scale vertically at a single server endpoint instead of through load balancers and multiple abstraction layers. This was what I believe to be a fatal mistake at the outset of this application's design. Maybe it can be fixed fairly easy, but I doubt it after seeing how it works internally.