Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
Log in  ::  Register  ::  Not logged in

The myth of the ‘shared development model’

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:

  • Firstly, this simple process causes confusion because some people perceive two different development models in this simple mode of work, and talk grandly about ‘shared’ and ‘local’ development models. Absurd. For a start, in my experience the sandbox often isn’t local and really should never be, and often gets shared (but only with a friend). We use both.
  • Secondly, there is the idea that having more than one developer working on a shared server is going to cause problems because they’d be working on the same code and both try to make changes. Before the introduction of schemas, it used to be possible, though it never happened to me.
  • Thirdly, there is the debate ‘at what point does your code get into source control?’. There seems to be some divergence of opinion here too. Unless the performance, and integration, testing of your job is done on the current build, you can’t be confident that it isn’t going to break something on integration. This implies that the shared server should be rebuilt from what is in source control. If the shared development database gets rebuilt overnight automatically from your VCS, then you can’t leave unsaved work on the shared server. This implies that work shouldn’t go into ‘trunk’ in source control until it is finished, and if your job is going to take some time, then it should be in a separate branch, and then merged. However, isn’t it more logical to just save the script for an unfinished job in secure storage occasionally? After all, it is only one person working on it and it doesn’t matter hugely if it gets lost. Actually, I prefer to lose jobs occasionally since I always seem to write SQL far better the next time around. I’ve never ever ‘reverted’ SQL code during active development.

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?

Total article views: 77 | Views in the last 30 days: 1
Related Articles

Source Control in SQL Server

One of the most requested features from SQL Server developers is the integration of source control w...


SQL Server Source Control Basics

Source control can and should play a key role in the database development and deployment process, an...


SQL Server Source Control Basics

Source control can and should play a key role in the database development and deployment process, an...


Shared Data Sources

Shared Data Sources


SQL Source Control - Q & A

After a webinar for SQL Source Control, there were a large number of questions left unanswered. All ...


Join the most active online SQL Server Community

SQL knowledge, delivered daily, free:

Email address:  

You make SSC a better place

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.

Join us!

Steve Jones

Already a member? Jump in:

Email address:   Password:   Remember me: Forgotten your password?
Steve Jones