Thank this author by sharing:
By Phil Factor,
This is a guest editorial from Phil Factor as Steve is on Sabbatical.
Database developers usually like to have a sandbox install of SQL Server to try things out, and develop stuff on, and a shared development server to do performance and integration testing for the databases they are working on. When a job gets to the stage that it passes all its unit tests and test assertions, then it gets onto the development server and thrashed. When it does what it is supposed to, with decent performance under load, and conforms to the error-handling standards in place, the job gets into the build, but not before.
Three points about this:
I like the idea of development teams finding a method of work that suits them rather than try to try to impose ‘best practices’ on them. As long as the source of all versions is in source control and the current version can be built from what is in source control, who cares? What do you think?
One of the most requested features from SQL Server developers is the integration of source control w...
Shared Data Sources
After a webinar for SQL Source Control, there were a large number of questions left unanswered. All ...
Looking for a good source control system for SQL Server development
Red Gate’s SQL Source Control (RGSSC) is very decent solution source control solution for database d...
As a member of SQLServerCentral, you get free access to loads of fresh content: thousands
of articles and SQL scripts, a library of free eBooks, a weekly database news roundup,
a great Q & A platform… And it’s our huge, buzzing community of SQL Server Professionals
that makes it such a success.