#9 Grant Fritchey, Database Dev Ops
Summary
Grant Fritchey giving an introduction to the world of database dev ops.
Details
Discussion with Grant Fritchey about what he does; origin of scary DBA nickname; what is dev ops, day to day dev ops tasks; DBA and developer interactions, communications, DBA’s favorite word is “no”; dev ops and source control, putting a DB in source control, integration with dev, auditing; moving DB from production to source control, ssdt, red gate sql source control, DBA resistance to source control, changing methodologies and mindsets, teething pains; tooling; keeping DB source in same place as software source, merges; benefits of source control, auditing, legislative requirements, tight coupling with dev, versioning, commenting, labeling a version; shared dev DB server vs individual dev DB server; comparing production to source control; continuous integration and automated deployment, complete replace of DB vs incremental builds, breaking changes; maturity of tools for CI, automated testing, app code vs TSQL for testing, testing before check in; replication and automated deployment; Entity Framework Migrations, breaking changes, EF Migrations vs SSDT and Red Gate SQL Source Control, up and down migrations*****; ORMs, dbas don’t like ORMs, performance, Glimpse to assess executed SQL; book choice - The Phoenix Projec, a parable on dev ops and making teams work together; Grant is presenting at the PASS summit full day seminar on query tuning, Grant’s book SQL Server Query Performance Tuning coming in Sept, wearing rainbow fuzzies for Argenis Without Borders.
See erratum below
Grant Fritchey is a technologist, evangelist, presenter, Microsoft MVP, and author. He has over 20 years experience in IT. He currently works for Red Gate Software as a product evangelist and as a consultant. Find out more here - Scary DBA blog
Grant’s new book - SQL Server Query Performance Tuning.
Grant is presenting at the PASS Summit 2014.
See Grant in fuzzies - Argenis Without Borders.
Book Recommendations
Erratum I made a mistake in my comment about moving between migrations with EF Migrations. The problem faced is if we are on migration 5 and need to deploy migration 2. Migration 2 knows nothing about migration 5 and can’t roll the database back. You need to get migration 5 to roll down and then deploy migration 2, but that is not ideal if all you want to is pick a deployment and deploy it.