out of pace with application development • Need of 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 • Your process has the strength of your weakest step • Time consuming and error prone • Releases are less frequent and risky
production environment • Database related bugs are only discovered after deployment to production • Manual tests 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 • Databases become a bottleneck in agile delivery processes • An easy target to blame
• 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 - automated tests • 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
• Without automation your are working in a amnesic state • Learn and forget it vs Improve and forget it • You do not want to depend on the “best of the best”
• Contract – change communication management tool • 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 – change communication management tool • 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
on development teams necessities • 4 week iterations • A bad choice • Different “language” from other teams • Desynchronization between operations and development teams
Kanban – 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
• Extending the Contract – change communication management tool • Applications ▪ Interaction points between apps and the others components of the system ▪ Behavior definition (configuration) • Databases ▪ Minimal context definition (data security) • Infrastructure ▪ Every team should know/contribute to the infrastructure model (Infrastructure as code)
is not enough, you have to deliver it • Communication framework for manage change • You can not stop change, but you can control it • Perspectives • Need for speed (time-to- market) (management people) • Need for control (error control) (operations people)
your org’s technical skills, practices, and cultural values around designing, building and maintaining systems, shipping software, and solving problems with technology.” • “It is how you get shit done” https://charity.wtf/2016/05/31/wtf-is-operations-serverless/
Code • Everything is code (Thank you virtualization!!) • Automation (cost, speed and risk) ▪ Leave the work to the machines and the thinking to you • The road to continuous… • App centered • The automation focus the application • Automation flies with the application • Minimal images, immutable instances/behavior
to manage your delivery pain • In order to be fast you need to have control • It´s a role • It´s a role that everyone must have • Your team is as strong as your weaker player • Choose whatever devops model/approach you want • You just need to hire competent people