How much control do we have over Application & Database version control?

0
Context I understand the basics of version control and working with Git, however, I haven’t found much functionality when it comes to version control with deploying applications and how it handles database recovery. I’ve done some research into this across Mendix Forums but I haven’t found much conclusive information.    Scenario Lets say on 30/08/2022 I publish build ‘A’ and then, on 05/08/2022 I then publish Build ‘B’. I then find a fatal problem which means I need to revert back to build A. During Build ‘B’s’ short life, users committed objects to the database.  I need to revert the application back to build ‘A’ , including all stored objects in the database.   Questions Is it possible to revert from build ‘B’ back to build ‘A’ without using Branches? Is it possible to revert the database from what it is currently, back to a previous date? If questions 1 and 2 are true, then can I choose to revert the build, but retain the current database or vice verca, could I keep this build but only revert the database back in time?    
asked
1 answers
2

Great question and something you need to be familiar. Let me try to answer you.

 

  1. Yes, when deploying, you'll create a deployment package, which is send to the cloud repository. From this repository you will deploy it to the acceptance/production environment. So when deploying Build B, then Build A is still available and reverting is deploying A again.
  2. On a nightly basis a back up is created, so yes this can be used to go back. Also recommended, before deploying build B, create a manual back up.
  3.  This is the tricky part. Since the Mendix model contains the Domain model as well, which is in control of the underlying database. So if Build A and Build B have the same domain model; You can keep the database with data entered when using Build B, while reverting back to Build A. However, when there are domain model changes, then there will be impact.
    1. When domain model in Build B is extended and reverting back to Build A, all additions to the domain model will be deleted from the database → thus data loss if containing data
    2. When domain model B has items removed compared to A → When deploying A, columns and tables will be added but empty

Additionally, a nightly backup of the database will have a reference to the used build/model package. So when restoring the a backup, the related model can be restored as well.

 

Note: above behavior of backup schedule etc is when using the Mendix cloud. When running on your own servers, backups and model repositories are in your own control and responsibility

 

Hope this shed some light on your questions

answered