Automating Database Change
In order to efficiently make incremental database changes you need to have a few things in place. One of the requirements is a continuous integration and deployment capability. Today I present a link to a well-designed framework by Alexander Karmanov which he has published on the internet for your review at www.simple-talk.com/sql/database-administration/an-incremental-database-development-and-deployment-framework..
We talked about this topic a few weeks ago. I’m returning to it specifically because of this posting by Alexander Karmanov which I came across recently. It details a home grown incremental automatic database deployment framework. If you are not clear about what could be done to enable automated deployment, this will certainly provide insight.
The goal is to make database change easy. As you modify your database design, the requisite database changes are tracked, and changes are deployed in a repeatable, automatable fashion, allowing change deployment through your entire software lifecycle.
Many companies have multiple sandbox databases allowing different developers to work on different aspects of an application without conflict. However, when they update or merge their software, if they don’t also merge in database changes, then their sandbox may not match the code utilizing it.
An automated framework allows a developer to update their sandbox on demand, synchronizing the database change with the merging of code by other developers. That’s really the goal…to have the ability to merge in database modifications in as simple a process as merging in application code changes.
Managing Server and Service Updates
Scott replies to Robert’s request for practices for applying updates in a Windows environment…
Our servers are hosted by an enterprise IT group. They send us developers any patches monthly, and we have it on our schedule to patch them that week, in a rolling failover fashion. When I came on board in early 2011, the architecture was SQL 2000 and Windows Server 2003, and dusty physical servers from 2004 that were slower than your spare laptop, so now that we are "caught up" to 2008 R2 and virtual, we like to stay current. I personally have the idea that this keeps us as secure and stable as possible, although I wonder if that is more or less true than saying that washing your car often keeps it from breaking down and helps gas mileage. Well, we’ve been approximately five 9s in uptime, much better than the non-updated apps and servers in other groups, so there’s that.
Thanks for the insight Scott.
As always, if you have any comments on these topics or any other topic of interest to you feel free to drop me an email at btaylor@sswug.org.
Cheers,
Ben
$$SWYNK$$
Featured Article(s)
Tips for using SQL Server 2012 Snapshot Replication
In this article, you can find some helpful tips to performance tune and optimize SQL Server 2012 snapshot replication.
Featured White Paper(s)
Top 10 Tips for Optimizing SQL Server Performance
read more)