Magento Environment Refreshes: More Than a git pull

Synchronizing code and data between multiple environments is a fact of development life. In Adobe Commerce, there are plenty of moving pieces and peculiarities to remember for refreshing lower level environments in a “clean” way; simply running a git pull or importing a database snapshot is not going to be enough to ensure your env is in a working state. If you periodically have to spend time with your team members debugging side effects of refreshes, only to come to conclusions like “that third-party Composer package got updated” or “you need to run app:config:import, you probably need to develop a consistent workflow around how environments get refreshed.

Every single time upstream code is pulled down in a Magento environment, these steps should be part of the refresh:

• composer.lock might have changed, so run composer install to get your packages up to date.
• New schema or patches might be present, so run bin/magento setup:upgrade to refresh the database. (Run it without the --keep-generated flag to allow static files to be regenerated as well.)
• Generated PHP classes might be out of date, so clear /generated to allow them to refresh.
• As is likely routine in many of your workflows, clear the cache!

Importing a fresh database snapshot from a higher level environment? Make sure you have a solid refresh workflow for this as well. The setup:upgrade and cache flush steps outlined above take care of most of the implications, but it’s good to have a grasp on what those implications are:

• Schema changes or patches might exist in the environment codebase that don’t exist in the environment where the snapshot originated, so setup:upgrade is a crucial step.
• The database stores a hash of the local on-disk configuration (in env.php and config.php), which is doubtlessly different between your environments. This is what app:config:import refreshes, but the setup:upgrade command that should already be part of your workflow also takes care of this.
• When importing a fresh database, running bin/magento indexer:reindex is usually well advised.

What About Updating Config Values?

Some dev teams might be accustomed to an additional step in their refresh workflow: Updating Store Config values that differ between environments (with config:set or manual SQL queries). I’ve been on teams that employed automated scripts for this very thing, but … then those teams grew into better workflows! This is precisely what locked on-disk configuration in Adobe Commerce is for. Config values that differ between environments - like integration endpoints or credentials, or settings appropriate for production but not development, like static signing - should be locked in env.php in lower level environments. And you should have a good workflow for reliably maintaining this configuration and distributing it to the members of your team.