Our company have developed in-house change tracking and distribution system. This system tracks database objects and database changes. The system uses two major components, change repository and change tool.
Change description contains list of objects this change affects and list of SQL scripts to execute to actually apply the change. The change tool is used to create the change from change description and sql scripts and put the change into the change repository.
The change tool is used to apply the change from the change repository into the target database schema. The tool will check dependencies, execute scripts, and create a record in the change repository about successful change application. These records are used to check dependencies.
Changes are grouped into changesets. The change tool can export changeset from the change repository into file, and can import changeset from file into the change repository. This is used to distribute changesets from developer change repository to client change repository.
On 25.02.2014 20:25, Jeff C wrote:
I am curious how everybody handle database change control. I am not talking about just source control for your code but the process of moving changes into the database, like procedure changes, alter tables, indexes, manually update of data, etc. Do you have a formal process to go through and what is that like if you are willing to share. We are a private company so things have been kind of light here and we don't have any credit card data. We source control, plus we have a project/bug tracking program that most but not all code changes are related to, and then all code is reviewed before moving to production. Oh and I have a ddl trigger enable to save all updates. But I don't feel like all of this tells a true story. I think we need something more formal and I am trying to gather ideas and opinions before I move forward with the idea. Thanks for any input. Jeff
-- //www.freelists.org/webpage/oracle-l
