Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
Author |
Topic |
Transact Charlie
Master Smack Fu Yak Hacker
3451 Posts |
Posted - 2012-07-18 : 09:27:46
|
Hello everyone.I'm curious to know what you would describe your approach to development (from a database / data perspective naturally), Do you stick to a waterfall model or a strict adherence to Agile methodologies. Do you use Test driven development / unit testing of the database? Do you have a continuous integration system for database development? Or even if you've gone the whole way to some sort of automated deployment platform?I'm interested because the company I work for recently embarked on a company wide agile adoption scheme with Thoughtworks.The reception was very, very mixed. We had some developers dive straight in and love things like pairing, test driven development, etc. And some that didn't and hated the idea of pairing in particular.Post Thoughtworks we kinda don't have a policy as such. We have project cards that get moved around but without stringent acceptance critera for example.So in short I'd say:1) We don't do test driven development as a whole (Its quite difficult to do in the db)2) We *do* use continuous integration of db code (which was a real pita to set up be we completely see the benefit)3) We don't pair often (though we probably should because we saw a definite quality benefit when we did)4) We have inceptions and generate cards -- they aren't quite agile stories but tasks. I'll admit that we fall down on acceptance criteria quite often.5) We don't do retrospectives, ever. Which I think is a shame.6) Project management revolves around identifying broad project goals and trying to estimate a time frame range for them. We still talk in terms of days rather than strict relative sizing for example..7) In general it's still a lot more manual when you have to change db code compared to other engine or front end code. We do use Redgate tooling which certainly made * administrating* the database much easier (SQL Compare is excellent)Anyway, I'm interested to know what you guys do.Transact CharlieMsg 3903.. The ROLLBACK TRANSACTION request has no corresponding BEGIN TRANSACTION. http://nosqlsolution.blogspot.co.uk/ |
|
nigelrivett
Master Smack Fu Yak Hacker
3385 Posts |
Posted - 2012-07-18 : 09:47:06
|
>> Do you stick to a waterfall model or a strict adherence to Agile methodologiesNo. During dev I assume that the system might need to be rebuilt daily which is a bit agile but agile has a lot of undesirable features. For a datawarehouse all of the structures and most of the code/packages are generated from a spreadsheet so there's minimal coding needed. This assumes that mostly the coding is mechanical (here's a datasource - get the data into a staging table, merge with dimension data - extract to datamarts) and can be generated from the table structures which are defined in a spreadsheet. Change the spreadhsheet - generate the system and run the job to populate it.1) It's difficult anywhere but there's no reason not to build a battery of tests that are always run and results checked - apart from time and talent available of course.2) It's good but I don't like relying on it for releases - also needs people to understand and follow the process.3) Problem with agile - often gets implemented as silo delvelopement which can end up very badly4) Depends on what the system needs. Slavish adherence to agile terminologly (pretending that is the same as the methodology) can be a bad thing.5) You probably do - just not formally. If you don't you are probably into silo development.6) days can translate into size.&) Built one system where the changes checked in created an update script which could then be run - but you had to check what was being released anyway to make sure it wasn't doing something that could take a long time so I'm not sure building and maintaining it was worth the effort.==========================================Cursors are useful if you don't know sql.SSIS can be used in a similar way.Beer is not cold and it isn't fizzy. |
|
|
|
|
|