SQL Is No Excuse to Avoid DevOps
I really enjoyed Thomas Limoncelli&#x27;s <i>Time Management for System Administrators</i>. I&#x27;ve also got <i>The Practice of System and Network Administration</i> on my shelf, and hopefully one of these years I&#x27;ll read it---maybe once my time management is better. :-) I like that Tom was practicing and advocating system-administration-by-writing-code way before DevOps, and to me he represents a tradition of automation that far predates the buzzwords.<p>I&#x27;ve lived in the world of Rails and Django so long, I sort of take schema migrations for granted. It&#x27;s interesting to see such a high-level person covering this ground; it reminds me of how much these frameworks have given us, and how so many organizations are still practically emailing around zip files of source code.<p>His Technique 2 feels harder to me: write the code to work on both old &amp; new schemas, and deploy the schema change after the code change. I know this is what Google does though, and I think it&#x27;s the only safe way to deploy rollback-able code changes. I&#x27;m curious who else is doing it, and especially how you are scheduling it. Especially with a CI&#x2F;CD workflow, I&#x27;m used to getting things integrated and letting them get deployed &quot;whenever&quot;. So how do you make sure the schema changes go out &quot;later&quot;, and what gating is required first, and how do you get buy-in to spend time on that after the feature is already live? I&#x27;m not asking about the technical how-to, but the organizational&#x2F;political how-to. For instance if you&#x27;re using Pivotal Tracker, do you make a separate PT story? Leave the old one open until the schema changes are deployed? What does it concretely look like?