Hear hear...
I give a presentation on "worst practices" from time to time
One of the many sections in there regards source code control/configuration management (remember, this is a worst practice talk, not a best practice - so the slides are meant to be ironic, the opposite of what is true)
In there I talk about how many people don't seem to consider their "database schema" (including code for goodness sake!) to be something that you put under source code control. Nope, you just let everyone in there and let them make changes - in the database directly.
They consider database code to be less than code - not worthy of being under any sort of change management. That is why I liked this blog entry I read this morning.
They got it right - dead on.
Think about it...
posted by Thomas Kyte at 10:59 AM
19 Comments:
Great Tom! Thank you for giving us such link. My job is related other than to DBA also to administer application deployment. The guidelines for database version control explained by Scott Allen are in my opinion very very interesting.
Tom absolutely agree !
note:
from
http://www.codinghorror.com/blog/archives/001050.html
,it is only 2 mouse-clicks to
".. one of the best tools you can purchase to help you in get your database under version control where it belongs":
http://msdn2.microsoft.com/en-us/teamsystem/aa718807.aspx
(take the very first hyperlink to
http://www.codinghorror.com/blog/archives/000743.html
and from there the first hyperlink again to Microsoft's tool)
where is Oracle's support for Schema-Version-Control ?
Could you please add some links for us ?
@Sokrates
you can use a tool from anywhere (eg: you would not necessarily goto Sun for java source code control...)
We do have the CM pack the CM pack but use whatever you already are using for the most part (plsql code, it is, well, code. .sql scripts are - well, code)
Tom,
It would be great if version control was built into the database. At least simple things like an ability to ask any object in the database (via data dictionary or supplied package or whatever) - "What version are you?" And build in version specification into the DDL commands like CREATE and ALTER + provide a database parameter to have an ability to make it mandatory, so no database change is made without specifying version as part of the modification command. Or even make versioning automatic, so every time and object is altered, it's version is incremented in the data dictionary.
It would also be great to have an ability to say "Hey, here is definition of version X of object Y, could you either bring the object in the database to this version or give me delta in a form of DDL or XML document, etc." Obviously not all changes can be made using this approach as many cases require scripting a migration path, but I think it is possible to at least build a defined framework within the database for it, so a product/process can be easily built on top of it. I.e. the version control of the database would be standartised by the database!
I think DBMS_METADATA package was a step in the direction I am very briefly outlining here, but I am not sure what vision is driving it and how far it will go?.. We had a chat about it during your seminar in Dublin a couple of years ago and I remember you saying that nothing was being planned along those line at that time. I wonder if anything has changed since? or can you tell?
Thank you.
Denis
@Denis
watch soon for details of stuff coming....
Can I add that commenting out old code and putting comments around new code does NOT constitute version control...despite what I've seen at some places
And what is "version control system" may I ask? It is a specialized database! So instead of suggesting that code should be kept under some kind of external source control system, it is oracle RDBMS that should be enhanced to have a decent version control system functionality.
@Vadim,
that is just like saying "and what is an HR system, it is a specialized database!"
"and what is LDAP..." (we built one of those, it is a product, an application however, not a core feature of a general purpose database)
"and what is (anything) but a specialized database"
No, this argument doesn't work.
Individuals and interactions over processes and tools.
Well, doesn't that mean we should listen to gurus and "get things done" rather than dig deep into testing and verifying?
@last anonymous person
what is the logic you used to get from that statement to "we don't need to test and verify"?
Perfect. Exactly what I'm speaking on at the Hotsos Symposium this year :-)
Presentation Title
Release Management for Database Applications
Abstract
While everyone likes to develop fresh versions of the hottest code, the reality is that our code lives on much longer than we would like sometimes. An ability to accurately identify the time line of changes to a database and package them for delivery into multiple testing environments is crucial to maintaining the integrity of custom database applications.
There are many commercial tools which purport to address this problem, but most of them do not integrate well into a standard source-code control and configuration management process. This paper will discuss techniques for managing disparate development, system test, quality assurance and production database images throughout a system life-cycle beyond initial development. Several approaches to change management along with their pros and cons will be discussed
@ dennis
Check this link
http://www.icewalkers.com/Linux/Software/533050/Schema-Version-Control-for-Oracle.html
Tom how do you do version control on asktom??
Can you share the information with us
@last anonymous person
the asktom application is very small, the application is just exported (from apex) and that is stuffed into source code control. the .sql scripts (well, the schema really hasn't been modified since dirt was invented) are as well.
And then that is extracted from source code control to be executed against the real system.
Hi Tom,
I was wondering if I can get your opinion on something:
Assuming you need to "install" a database, and you have two components, both of which are maintained well under versioning control:
1) A database export (verified that it can be imported into a database)
2) A master script that can be run via SQL*Plus ie a script generated and tweaked via the showfile option.
Do you have any preference on which of the two you would use?
Regards,
Arun
@Arun
the export would likely be an OK way to go - nice, self contained, no paths to mess with...
I've seen both done, the sqlplus script is by far the most used, since you can sort of program it with PLSQL and deal with errors. The dmp file would be problematic for error handling.
Tom,
One link away from the blog you linked to was a post about database development. The first rule listed was,
1. Never use a shared database server for development work.
The author didn't make it clear whether he meant code development or schema development. Too often these two overlap -- while writing code you realize you need a new column.
I think that multiple schema changes occuring to individual copies could get quite confusing, whereas code is, just as you say, code. All the same challenges apply.
He lists lots of "tools" supposed to make this easier. Most seem to do nothing but perform schema diffs. I think diffs are a bad idea for promotion - not every change goes every release.
Perhaps the answer/opinion I'm looking for is "new question" under the AskTom rules. Maybe you'd consider a new blog entry?
On a seperate note, I'm salivating over the idea that I could potentially add custom properties to schema objects. I don't know why this hasn't been done before. A single note field and only for tables and columns seems so 1970's.
@Mark
... I think that multiple schema changes occuring to individual copies could get quite confusing, whereas code is, just as you say, code. All the same challenges apply. ...
schema changes are code. Just like in the old days when you pulled the cobol copy book to modify a structure, or you updated a C header to change a struct.
Hi Tom,
I couldn't agree anymore strongly on source code control. The thing that I would like to point out is that the worst offenders of not following this source control creed are the DBAs. Most environments I've been in for that past 10 years have had source code control for all of the database code in "development" but I have yet to see an environment where the DBA's code is under the same form of protection as well as scrutiny. And I'm talking even simple stuff like, the init.ora being in source control.
POST A COMMENT
<< Home