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! @EdPiairo, #DevOpsPorto
• Scrum for the masses (>20) • Pure Scrum approach – operations as development team • 2 week sprint, sprint goal • The team was “too reactive” @EdPiairo, #DevOpsPorto
• 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 @EdPiairo, #DevOpsPorto
• 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 • High dependency in a person (database specialist) • Fear of making changes @EdPiairo, #DevOpsPorto
databases • 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 @EdPiairo, #DevOpsPorto
databases • 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 @EdPiairo, #DevOpsPorto
for databases • 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 @EdPiairo, #DevOpsPorto
• 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 • 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 @EdPiairo, #DevOpsPorto
databases • 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 @EdPiairo, #DevOpsPorto
rules • Rule 1: Script version (timestamp) • Rule 2: Operation type • Rule 3: Object type • Rule 4: Object name Example: V20160220.1100__Create_TB_MyTable.sql • One script, one operation type, one object @EdPiairo, #DevOpsPorto SMALL BATCHES
Contract – communication, collaboration mechanism for 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 @EdPiairo, #DevOpsPorto
development teams necessities • 4 week iterations • A bad choice • Different “language” from other teams • Desynchronization between operations and development teams @EdPiairo, #DevOpsPorto
– 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 @EdPiairo, #DevOpsPorto
enough, you have to deliver it • Communication and collaboration framework for manage changes • 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 @EdPiairo, #DevOpsPorto
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 @EdPiairo, #DevOpsPorto
• Depends on • DevOps team structure (http://web.devopstopologies.com/) • How many different topologies • Your clients • Good ideas • Have cadence/rhythm • Alignment with development team • Visibility, transparency and sharing (from doers to operations enablers) @EdPiairo, #DevOpsPorto
devopsporto
akkeylab
meow_noisy
tebiki
aiqlab
biwakonbu
naitosatoshi
rainerhahnekamp
kentaitakura
freee
bicstone
toru_kubota
databricksjapan
danielanewman
lauravandoore
deanohume
morganepeng
pedronauck
denniskardys
colly
lara
bcantrill
addyosmani
brad_frost
bermonpainter
![ABOUT ME Operations for databases @EdPiairo, #DevOpsPorto @EdPiairo https://pt.linkedin.com/in/jesuspiairo [email protected]](https://files.speakerdeck.com/presentations/131eed48d96f406bb3db2e275ef0de28/slide_1.jpg){kind=link}
![Q&A Operations for databases @EdPiairo https://pt.linkedin.com/in/jesuspiairo [email protected] http://www.eduardopiairo.com/ @EdPiairo, #DevOpsPorto](https://files.speakerdeck.com/presentations/131eed48d96f406bb3db2e275ef0de28/slide_37.jpg){kind=link}