The real metric, the only one that matters, is that within 2 release cycles, just 2, our customers were raving about how much more stable the software was and how it no longer took entire weekends to do upgrades. I could share those stats, they are eye-opening…so much so that people think the metrics are bullshit. If you are an ISV, ie you support many customers each with potentially different versions of your software, different release branches, etc, then I don’t know how you can possibly manage WITHOUT CI.Īt the ISV I consulted for we put together a lot of metrics around reductions in rework, bugs, etc. If you support just a handful of dbs where there is only one or a handful of supported releases (like one internal website) then you are probably OK not doing CI. We also run our tsqlt unit tests at this time as well as data compares for lookup/model/system data.įrankly, not all of my customers need CI. At the end of each “build” we run a database diff utility to ensure that each upgraded version matches the “net new” version of the database schematically. We grab lots of metrics such as timings for each build. We execute them against each release of our database found in the wild. We apply our database scripts in toto for every build, meaning the scripts are idempotent. Biggest benefits are customer satisfaction (less bugs, quicker time to market) and less developer rework. For table DDL this is EXTREMELY critical. What benefits have you achieved by using CI? For ISVs that support multiple “versions” of databases and software this is absolutely critical to ensuring changes work with each of the different versions. It’s actually a quite simple process using powershell. How many person-hours did it take to get CI working? about 80 How many database developers you have? about 100, 300 developers total What benefits have you achieved by using CI?
How many person-hours did it take to get CI working? We’re also moving towards automated deployment, but not quite ready for continuous deployment. I’m a huge advocate for it and evangelize for it’s adoption at every opportunity. each change is a separate script so to get the current version you always have to run through all the operations in order, no idea of current state in source Reply just tables/data store – LINQ and ORM everythingĬ. And in the non MS world it’s even worse – options seem to be –ī. However have to say that it is frustrating as someone who has been doing this for years to still have to make the argument of Why and then have to still get the duct tape out to get it done. Have always wanted to an actually presentation on all of this, but…life. And outside of MS technologies where SSDT doesn’t exist….such a pain. Saying that the tools are still so raw that keeping it going is an ongoing investment – for example Service Broker introduced new annoyances to ensuring it worked.
#Sql cdc code
Recently we’ve been working on overhauling it so that on git checking we’ll spin up a new SQL Server instance via Chef, deploying code via Jenkins and testing.Ĥ,) Countless – majority of our work is database heavy and significant logic within the db – so having procs be unit tested on check ins, or creating new unit tests for bugs has been invaluable. We can also target multiple versions of the same database. Assuming tests pass do an deployment to a database with data already in it.
Data is managed through SPs within a Unit Test schema (SSDT partial project). Personally I’ve been an avid DataDude user since it came out in 2006 (within VS 2005 UI).ġ.) 5 database developers working closely with 2 DBAs (separate reporting structure)Ģ.) Was myself and 1 App Developer about six weeks – but that’s because we did SSIS, SSRS and SSAS as well.ģ,) TFS, SSDT, SQL Server – Since 2011 we have been using a custom TFS build – the way it work is on checkin it deploys a brand new database from scratch, runs all the database unit tests (SSDT ones not tSQLt), the tests create the data and destroy the data after each test. We have had automated SQL Server Database Continuous Integration and Continuous Deployment in Dev and Test since 2011. Ok you hit a nerve (although I imagine you knew that already), so apologies if a soap box comes out:
0 kommentar(er)
