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?