So I am curious on what the workflow of larger companies or projects is with MODX.
How do you handle changes on LIVE and DEV sites?
(push changes on DEV to LIVE, but also keep content and user changes)
How do you allow multiple developer or teams to work on 1 site at the same time without sync errors?
(a current client want to start to use Docker, but how do you handle the DB?)
Any general ideas for a solid, Git based, workflow to stage changes with other developers and push to live in a easy way?
Firstly, we made the decision that content changes are always made on LIVE and pulled to DEV, because there is no good workflow we found for bidirectional content sync. No matter what you do it’s going to need human input to merge conflicting changes. With that proviso:
We make heavy use of Gitify to keep our chunks/snippets/plugins/templates/ContentBlock configurations and more under source control.
We sponsored the update of Gitify Watch • Gitify Watch • modmore.com to allow these (specifically chunks) to be edited in LIVE and changes not get lost, but it’s been hard to get buy-in from customers to use it, and on a recent project we’ve excluded chunks from Gitify so they are edited direct on LIVE like content (so we use static resources for those we want to version control).
Everyone has a local DDEV development environment and can pull the latest LIVE database at any time (personal information is automatically stripped before it’s downloaded).
They then develop like any PHP web project, run gitify extract and commit their changes to Git. Git handles the sync errors and conflicts.
When ready, a deployment is made to LIVE.
Gitify and a deployment script to roll the changes out on live
So this varies depending on the project. In its simplest form it’s a script that is run on the hosting server(s) and does a git pull to get the latest changes, runs gitify build and clears the MODX cache.
In practice they’re more complex than this because there’s CSS/JS assets to build and minify, composer packages to install, other caches to invalidate etc. Sometimes these deployment scripts run within Ansible to provision servers - we haven’t yet moved to Dockerising environments so that is yet to come.
The nicest deployment process is when we push to a specific Git repository and it automatically triggers the deployment.
Just a VERY basic example case and final question from my part
I have a live site, with a contact form. This uses some chunks, snippets and site settings.
Now the client wants a extra field maybe and edit the snippet to send the mail to somewhere.
Do you pull the DB, make the changes and the somehow inject the DB (with the new features) into live? That would override any changes made during dev time.
Am I missing something? EDIT oooohhh I see now Gitify build also added all new settings to the LIVE database
Or are you actually adding the new needed site setting to live directly?
(my problem now usually is that I make all the new features on DEV, test it, and once it works I have to redo some work since on live the new MODX config and settings are not there)
Yes, so my workflow (assuming I already have a DDEV environment, local checkout of the site etc etc) would be:
Commit any changes I have in my local environment, so they are backed up
Download and load the latest copy of the LIVE database into my DDEV environment
(optional steps)
Run ddev extract to see what’s different from the files in Git. This is a helpful reminder if I’ve forgotten to fetch the latest changes from Git and someone else has made changes
OR Run ddev build to load what I have been developing into the LIVE database backup, so I see my changes again
Now to work! Edit the chunk to add that extra field; edit the snippet; test locally
Run gitify extract
Check the changes in my Git client (I use Fork, other clients are available) and commit them to my Git repository
Deploy to live
We have been excluding site_settings from Gitify, because they will often be different between LIVE and DEV (e.g. SMTP connection details, Elasticsearch URL) and contain passwords etc which we don’t want in our Git repository.
I wrote a MODX Plugin called SystemSettingsOverride to remove the pain of having the wrong (LIVE) settings in your dev environment. It lets you set any system_settings from a file on the filesystem. This means you don’t have to edit the system_settings every time you import a new copy of the LIVE your database, because the details in the file are used in preference.
Oh, the other change you’ll want to make is to core/config/config.inc.php to override your database credentials in your development environment.
