How to version control a source code which communicates with database?

49 Views Asked by At

I'm working on a C++ code which communicates with a MySQL server. The C++ code and MySQL server has dependencies on each other. I'm using git for version control of the C++ codes, and use MySQL Workbench for managing database. Whenever I make changes on Db queries, tables or Stored Procedure's; Db and C++ code must be at the matching state. I don't know how to manage database with git. And this allows for possibility of making mistake when moving from Dev environment to Prod. What is the best practice of version controlling a distributed system like this?

1

There are 1 best solutions below

0
AndrewR On

Both database congfigs/scripts/schemas and C++ code typically reside in different code repositories.

First step is to keep in sync both deployed code and database in sync with their corresponding repositories (but not to each other, more on this later). Typically, there are two options: manual - via some kind of SOP (standard operation procedure), or automated - have a pipeline/tool which monitors changes in those repositories and builds&tests&deploys these changes via step by step process over stages (dev/preprod/prod).

The second step is who to keep DB and the code in sync. For example, if a table is renamed, the code need to know that the name changed. The big question to answer: do we want the system to be online (operational) while we migrate the change.

If the system may be taken offline, it's good as it simplifies things. The operator or the automation would cut the usage for the system and separately update DB (schema migration) and deploy new code. The system is brought back online after.

If the system must stay available, there are two items to cover. First the database migration, that may be tricky and tools like copy-on-update may help. This is tricky and depends on the database and the nature of db change.

The second part of keeping the system operational is to have the deployed code to be working while db is being updated. When the code is deployed, it sees the older DB, and then the DB is updated while the code is already there. Basically, the code need to be written to support DB in state of both before and after change. That's approach is called backward/forward compatibility.