deployment strategies?

[jamie]

Would anyone like to share their deployment strategies?

I’m working on setting up the usual alpha → beta → demo → golden flow, but I’m running into issues with data configuration files and extensions.

Thanks!

[emillod]

It depends..

We have our own deployment flow for our internal extension. First, we work on changes locally. A good next step is checking through GitHub to see if all tests pass. If they do, the changes should be sent to the sandbox environment (this can be automated via GitHub). After testing in the sandbox, it moves to production.

Currently, we're developing the company extension locally and pushing it directly to production. It's not ideal due to time constraints, but we're improving the process. The next step is integrating GitHub to ensure the extension goes to production only if tests pass.

We have customers which use the sandbox for testing before the extension is pushed to production.

[jamie]

That sounds a lot like our process, with sandbox being replaced with demo

Would you care to share your .gitignore, tests, and whatever else you can about he process?

[emillod]

jamie
so basically we've created our own ext-template repo which contains more things. After i clone repo with our internal extension, i can simply write "make full" and it'll automatically create whole environment in docker with espo and other related services such as smtp server and ngrok. It'll automatically populate some data from production to have all required information on local environment. It'll also copy all extensions to local instance.

We're using phpstan with most strict rules to make sure that code is in good shape.
In regard to tests, we're writing tests for main functionalities such as converter of currency because it's crucial to our billing process. We have to take currency from previous day, so we have to make sure that even if it's a holiday or weekend, it'll take proper rate. We're testing other things such us proper numbers on documents, our internal integration with SMS provider to make sure that it's working internally (if we create sms inside in EspoCRM) and externally if one of our customer will send sms via their app, etc. It's impossible to test everything, so we focused on crucial parts of our system.

[jamie]

sounds like a wonderful setup, care to pop by Manchester and help us out <lol>

Mind posting your .gitignore file in here?

[emillod]

My Associate would kill me for doing charity from our company haha
Here you have .gitignore from one of our repos: ext-gotenberg/.gitignore at main · dubas-pro/ext-gotenberg

[jamie]

My Associate would kill me for doing charity from our company haha
Here you have .gitignore from one of our repos: ext-gotenberg/.gitignore at main · dubas-pro/ext-gotenberg

is for the good of the community, the more people use Espo, the more will be available to buy your services and products

Hum, nothing stands out that I should add to my own
]

# EspoCRM specific
application/Espo/Modules/*/Resources/metadata/cache/
application/Espo/Modules/*/Resources/layouts/cache/
client/modules/*/res/cache/
# Ignore entire data directory
data/*
# Cache & temp files
data/cache/
data/upload/
data/temp/
data/session/
# Composer dependencies and Node modules
vendor/
#node_modules/
# Logs
data/logs/
*.log
# Backup files
*.bak
*.tmp
*.swp
*.swo
# IDE/editor settings / OS files
.vscode/
.idea/
*.sublime-workspace
*.sublime-project
.DS_Store
Thumbs.db
# Git
*.orig
# Apache/Nginx/PHP environment files
.env