Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Continuous Delivery for Databases - Longer

Continuous Delivery for Databases - Longer

Continuous Delivery for Databases - Stockholm Oracle Meetup - Longer, with more details on tools approach

Marcus Philip

June 16, 2015
Tweet

More Decks by Marcus Philip

Other Decks in Programming

Transcript

  1. Agenda Why aren’t we doing it? Why should we do

    it? How could we do it? How do we implement it? Did it work?
  2. Why aren’t we doing it? Mistrust in automation Lack of

    awareness of problem and solutions DB perceived as special • “Core to business” • “Not like Java applications”
 But often less change control than for applications
  3. CD - DBA: “I’m a control freak, so I want

    to apply the changes to production myself, by hand”
 - Me: “Me too. That’s why I want to automate and use the principles of CD”
  4. Rationale Y’all know why you should do CD, right…? •

    The same benefits applies to the DB! The problems we are trying to solve • Inconsistent environments • Slow and error prone production deployments • State not known and not visualized • Long feedback loops • Long lead times
  5. Principles of CD 1. Repeatable, Reliable process 2. Automate everything

    3. Version everything 4. If something is painful, do it more often 5. Done = released 6. Build quality in 7. Everybody is responsible 8. Continuously improve
  6. 3. Version everything DDL, DML, Stored Procs, Triggers, SQL scripts,

    deployment scripts, metadata, configuration, etc. VCS is the only entry point to the delivery pipeline • Traceability • Reliable basis for release notes
  7. 5. Done = Released
 6. Build quality in
 7. Everybody

    is responsible Nobody can hide in their dungeon Empower teams • Production responsibility • Focus on end-to-end delivery Development team => Delivery team
  8. 8. Continuously improve The most important? Crap + Continuous Improvement

    = Awesome Good Pattern: • Develop empathy for your up and downstream
  9. Considerations Maturity of organization • Majority and informal leaders willing

    to change? • Champions willing to drive change? • Can everyone keep discipline?
  10. Considerations Branching • VCS have branches, but our databases do

    not • Applying same changes in test and prod is not enough, also need same order • Branching patterns tried: • Develop, Master & Fast Track (Release from Master or FT) • Master, Feature, Release Development process will be impacted
  11. Starting the transition 1. Select appropriate tool(s) 2. Sync code

    base with production 3. Standardize environments 4. Implement pipeline 5. Get access to production
  12. Tool Requirements • Give traceability - versioned DB schema •

    All changes are version controlled • Scriptable and integrate with other tools • Changes must propagate with minimal intervention • Easy to realign map & reality • Parallelization of development possible • Minimal impact on dev tools and process • Support for all types of DB objects used
  13. Tool approaches Track changes in a table in DB •

    Checksum & status per change • Knows what’s been applied • Makes prod refresh to test environment simple Metadata to annotate deploy order & type of script A. File/folder naming conventions B. Change log file
  14. e31af80 e31af80 1 | my_table.sql | a6f86b… | EXECUTED 1

    | my_table.sql | a6f86b… | EXECUTED
  15. e31af80 e31af80 1 | my_table.sql | a6f86b… | EXECUTED 1

    | my_table.sql | a6f86b… | EXECUTED 1 | my_table.sql | a6f86b… | EXECUTED
  16. Tools Liquibase - Great, but some XML needed dbMaintain -

    Great, but community dead Sqitch - Great, if you’re OK with patching in Perl FlyWay - Great, but PL/SQL need #128 Datical - Maybe. Enterprise software… DB Maestro - Maybe. Enterprise software…
  17. Practices Common CI and CD practices • Smoke test before

    check in • Check in often • One change per check-in • If anything fails, stop the line • Smoke test deployments automatically • …
  18. Obstacles 24/7! • Queues and jobs cannot be shut down

    Global vars in conjunction with connection pools • Need to restart app servers at DB deploy Oracle cluster does not propagate changes • Shut down all nodes but one at deploy time
  19. Real Obstacle Resistance to change • Sell, sell, sell! •

    Be seen as an agent of improvement, not frustration • Learning curve • Some consider themselves ‘above the law’ • Save one day, f*** up the next
  20. Summary 1. It’s possible! 2. It’s worth it! 3. There

    will be compromises! • Choose your battles • Continuously improve