Currently, I have three instances of SuiteCRM, Development, Testing, and Production, with Dev running locally on my desktop, and Test and Prod running on separate web servers and each of the three having its own database. When it comes time to upgrade SuiteCRM, I run the upgrade first on Dev and Testing. Then, assuming no problems, I run it on Production after making a full backup of both files and database and without anyone using the system. So far, so good.
What I’d like to do is put the code base in git and deploy the Test and Prod instance in Docker containers in a Kubernetes environment. I run Dev in a container on my desktop. When I commit changes to GitLab, the Test tier is automatically deployed. I’d do the same with Prod, if and when I figure everything out. However, I have two issues I’m not sure how to handle (assuming the can be handled at all):
If I apply an upgrade package to the Dev version, it makes changes to both files and database. When the files are committed to git and deployed to Test, the test database obviously doesn’t have any associated changes. Would running Quick Repair and Rebuild be expected to handle that situation?
The users of the system create new fields and even entire new modules, directly on the Production version of the system. The files created by Module Builder or Studio in that process would be lost when a new instance of the site is deployed because they are never committed to git. Any changes to the database, however, would still be there. So, again, would running Quick Repair and Rebuild be expected to handle that situation?
It’s quite possible I’m missing something obvious but I haven’t found anything in the documentation about either of these issues.