3. DBOPS, DEVOPS & OPS
1.Before Scrum
2.Scrum
3.Kanban
4.Scrum + Kanban
Time line
4. DBOPS, DEVOPS & OPS
1.Before Scrum
2.Scrum
3.Kanban
4.Scrum + Kanban
Time line
5. DBOPS, DEVOPS & OPS
Before Scrum
• Before Scrum - The “real agile” method
• Centralized decision mechanism
• Growing phase
• Size (5 to 15)
• Complexity (more and more components)
7. DBOPS, DEVOPS & OPS
1.Before Scrum
2.Scrum
3.Kanban
4.Scrum + Kanban
Time line
8. DBOPS, DEVOPS & OPS
Scrum
• Scrum - The “magic” scrum
• Scrum for the masses (>20)
• Pure Scrum approach – operations as development team
• 2 week sprint, sprint goal
• The team was “too reactive”
9. DBOPS, DEVOPS & OPS
DbOps – The beginning
Application #1
Application #2
Application #3
Shared database(s)
Team #1
Team #2
Team #3
Team #T-SQL
10. DBOPS, DEVOPS & OPS
DbOps – Building a process
Source
Control
Continuous
Integration
Continuous
Delivery
Database
+
Application
11. DBOPS, DEVOPS & OPS
What’s so special about databases?
DbOps – Building a process
12. DBOPS, DEVOPS & OPS
DbOps - Motivation
• Databases are 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
13. DBOPS, DEVOPS & OPS
DbOps - Motivation
• Bugs in 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
14. DBOPS, DEVOPS & OPS
DbOps – Building a process
Source
Control
Continuous
Integration
Continuous
Delivery
Automation
+
Change control
15. DBOPS, DEVOPS & OPS
DbOps - The value of 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 - 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
16. DBOPS, DEVOPS & OPS
DbOps - The value of automation
• 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”
17. DBOPS, DEVOPS & OPS
DbOps - Communicating through a contract
• 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
18. DBOPS, DEVOPS & OPS
DbOps - Communicating through a contract
• Contract – change communication management tool
• Rule 1: Script version (timestamp)
• Rule 2: Operation type
• Rule 3: Object type
• Rule 4: Object name
Example:
V20160220.1100__Create_TB_MyTable.sql
19. DBOPS, DEVOPS & OPS
DbOps - Communicating through a contract
• 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
20. DBOPS, DEVOPS & OPS
1.Before Scrum
2.Scrum
3.Kanban
4.Scrum + Kanban
Time line
21. DBOPS, DEVOPS & OPS
Kanban
• Kanban 101
• Focus on development teams necessities
• 4 week iterations
• A bad choice
• Different “language” from other teams
• Desynchronization between operations and development teams
23. DBOPS, DEVOPS & OPS
1.Before Scrum
2.Scrum
3.Kanban
4.Scrum + Kanban
Time line
24. DBOPS, DEVOPS & OPS
Scrum + Kanban
• Scrum + 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
25. DBOPS, DEVOPS & OPS
DbOps - Communicating through a contract
• Extending the Contract – change communication management tool
• Applications
• Databases
• Infrastructure
26. DBOPS, DEVOPS & OPS
DbOps - Communicating through a contract
• 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)
27. DBOPS, DEVOPS & OPS
Why DevOps? (Definition)
• Developing software 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)
28. DBOPS, DEVOPS & OPS
Operations
• “Is the constellation of 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/
29. DBOPS, DEVOPS & OPS
Operations future
• #Insert_Here# … as 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
30. DBOPS, DEVOPS & OPS
DevOps – Final thoughts
• Helps 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