Database operations Automation Source Control Continuous Integration Continuous Delivery The definition and the interpretation of the covered concepts are attached to the cultural context of a specific organization on a certain period!
• Databases are out of pace with application development • Synchronization between development and DBA teams • No traceability of database changes (changes history) • What changed? Who? When? Why? • Manual databases processes prevent the CI and CD utilization in their full extent • Time consuming and error prone • Releases are less frequent and risky
• Bugs in production environment • Database related bugs are only discovered after deployment to production • Manual or inexistent tests • Fixes and hotfixes have time cost, what can lead to delay a release • Database setup time of a new environment • Expensive process for new clients
automation • Enable control over database development • Increase speed of response to change • Keep a versioned “history” of database states • Greater reliability of the release process • Increase release frequency through repeatability of processes • Reduce time spent fixing bugs • Remove/reduce human intervention in the release process • The build step is automatic triggered by a “push” into source control repository • The deploy step is automatic triggered by a successfully build process
automation • Without automation your are working in a amnesic state • (Re)Learn and forget it vs Improve and forget it • You do not want to depend on the “best of the best”
Source Control • First step in your database deployment pipeline • Traceability through change history • SQL as documentation • Shared code-base and shared process • Enforceable standards to reduce conflicts • Fundamental resource: SQL script
• State based solutions • Script represents the current database state • Your source of truth is how the database should be • Migrations based solutions • Script represents a migration • Migration represents how to transition to the next database version • Your source of truth is how the database should change Flyway: open source database migration tool • Simplicity: easy to setup, no need to install • Zero dependencies (java + jdbc) • Scripts are written in SQL
contract • Contract – communication mechanism for change management • Set of rules and expectations • Define responsibility frontiers • Sets a common language Application #1 Application #2 Application #3 Shared database(s) Team #1 T-SQL Script Team #2 Team #3 Team #T-SQL
contract – The pipeline • Contract – communication mechanism form change management • Should be reflected in your development pipeline • The better/clearer your pipeline, the less you need to document (your code is your documentation) • Everything is negotiable in the contract, except its application
development teams necessities • 4 week iterations • A bad choice • Different “language” from other teams • Desynchronization between operations and development teams
– The best of two worlds • 2 week sprint, sprint goal • Task definition was based on teams necessities and our necessities • Team capacity < 70% (enough bandwidth to react) • Strong and disciplined team • Integration in solutions design • Operations as a service
enough, you have to deliver it • Communication framework for manage change • You can not stop change, but you can control it • CAMS • We change the culture (with lot of negotiation and evangelization) • We invested in automation (started with 0 automation in a never ending automation journey) • We conquer work flow visibility, so we were able to start measure • We spread the contract across the organization
manual databases changes to about 98% automatic changes (100% controlled changes) • On average 200 scripts were created per day • In one year we achieved 10k scripts • We went from supporting only 1costumer to 4 costumers at the same time • Each week, costumer requests were delivered • Fixes were applied whenever necessary