Re: Source Control for DB objects
- From: Nigel Thomas <nigel.cl.thomas@xxxxxxxxxxxxxx>
- To: JChirco@xxxxxxxxxx
- Date: Fri, 5 Aug 2011 18:15:09 +0100
On 5 August 2011 16:42, Jeff Chirco <JChirco@xxxxxxxxxx> wrote:
> What about this scenario.
> Say user A is working on a package and then user B needs to finish working
> on the package where A left off. Is the only way user B can get user A's
> changes is if he commits/ check in his changes? But it is not in production
> yet so how can I tell what version is in production. Currently I only have
> my developers check in their source when it has been moved to production,
> that way it is very easy for me to tell what is in production.
> Thanks
>
> Jeff | Database Administrator
>
>
Jeff
You should distingush between "checked into SVN" (or any v/c system) and
"ready for production". In a multi-user world, the only way B should see A's
change is if A checks it in and B checks it out (eg, by using svn update on
his working copy).
When the change is complete and fully tested, it should be applied to
production. There are loads of ways to keep track of what is in production
using SVN or other tools. For example:
1) When your scripts are ready for production, make a tag or label - then
you can see each / any release into production
2) keep a production branch- merge changes into that branch only when they
have been tested.
If you are using SVN, these approaches are described in the svn red book
(google for it). All decent v/c systems support these and other techniques.
Essentially, if you don't check in changes until stuff is in production, you
don't have full control / audit of who did what until after it has been
released. And all those interim checkins give you a trail of checkpoints
(like savepoints before a commit) which is way easier than everyone keeping
their own private archives of scriptXYZ.sql.20110805v32 or something like
that.
Cheers Nigel
Other related posts:
