SuiteCRM Deployment to Docker/Kubernetes

SuiteCRM Forum - English Language Developer Collaboration
1

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):

  1. 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?

  2. 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.

– HHH

2

Hey @HartleyH :wave: Long time no see.

Ok, I will try to answer best I can but perhaps other folk can explain abit out how they execute their uat/prod instances.

  1. If it is an upgrade pack then yes, you should be able to Repair & Rebuild to trigger the database to update. (You may have to run it R&R and scroll down to the bottom of result page to actually EXECUTE the SQL query)

  2. This is a little more complicated. From my experience if you have database change that the file does not then it will cause mismatch. You are somewhat correct in your assumption but logically how would the system know what is the “master” instructions? the database or the files? Now would this be a matter of process? Surely it would be best to frequently keep the prod, test and dev inline with each other (Yeah, that was a rhetorical question, Ash :rofl: ) so in order to do that you will eventually need to pull down those file changes from production? Can you not include that process as part of the development or support cycle provided? Ensure that whenever working on the dev it frequently updated with any changes made in production, only updating production when changes in dev are ready etc.