There are many different options for managing source code of course. Perhaps one of the most referenced is GitHub and the integration tools and such are very strong for managing your source and application bits and pieces.
For some reason, many don’t think about including scripts, table structures, basically all of the things to do with the database, in their version control. Perhaps I’m unusual, but to me, these are both easy to script out, and as critical to have a version control system around as the source code running your applications.
So many times we’re looking for what changed. What changed at the database schema level, or the automation and jobs, or other component parts of the database is the target of that very question many times, particularly if you have different people with access that you may not know about… or, my favorite, if you’re responsible for managing departmental databases. Why? Because as soon as people see a “database” is involved, they come to you, the person in charge of databases. Never mind the fact that you had nothing to do with managing the system or setting it up or “that thing last week where some columns were tweaked to make things better.”
How do you handle this type of versioning?
There are many things to consider – from the DDL to the stored procedures, from jobs to full-text catalogs and all of those things in between… missing an element can be risky.
Typically, this is more of a reference activity. Hopefully you have a backup and recovery system that takes care of not having to actually rebuild the world. So what the versioning ends up being is often a sanity check and research tool.
If you need to know what schema changes were done to support “XYZ” then you can go back and look and see what changed. This can be a lifesaver in case a change causes issues with your application.
Perhaps one of the more critical things to implement with version control is a process to make sure it’s updated regularly, that you’re annotating the changes, and that there aren’t gaps in the commit efforts that miss changes. It’ll be very important to build the commit and documentation process into the release process so that, as you roll things from development to test to production, you are keeping things updated.
If you’re simply expecting the database folks to continually commit in case something changes, that gets old really fast. I’ve seen many well-intentioned teams get out of sync very quickly if these assumptions are driving the process.
How do you handle versioning for your systems?