This document discusses database automation and the mistrust that can exist around it. A survey found that while continuous delivery is on the rise, database automation sees less adoption due to mistrust. Database changes can impact whole systems, so any automation must be done carefully. Script-based version control and deployment can lead to issues like out-of-process changes and working on wrong revisions. Integrating databases into version control and continuous delivery processes through tools like DBmaestro can bring more visibility, control and trust to database changes and deployments. This is done by enforcing best practices, tracking who made changes, and facilitating automated but safe deployments through capabilities like baseline comparisons and impact analysis.

1. In (Database) Automation We Trust
Yaniv Yehuda

2. Before We Begin
• You will be on mute for the duration of the event
• We are now talking so please type a message
in the Questions box in the Control Panel if you can’t
hear us (please check your speakers and
GoToWebinar audio settings first)
• If you have questions during the session, please submit
them on the Q&A bar on your gotowebinar dashboard
and we will address them at the end
• A recording of the full webinar will be put up online
2

3. 3
Presenter
Yaniv Yehuda
• CTO, Co-Founder at DBmaestro

4. About DBmaestro
• Founded in 2008, product launched in 2010
• Founded by Yariv Tabac and Yaniv Yehuda
• Headquartered in Israel, Global Operations

5. In Database Automation
We Trust!
(Or do we?)
5

6. Recently Conducted DBmaestro Survey
• Over 150 Companies
• Over 200 participants
• Continuous Delivery is on the rise!
• Database Automation meets mistrust…
• Why?
• What can be done?
6

7. Recently Conducted DBmaestro Survey
7

8. Why automation?
• What is Continuous Delivery?
• Why is it important?
8
Automation

9. Automation is the Name of the Game…
Continuous Integration
Continuous Delivery
Continuous Deployment
9

10. What is Continuous Integration?
• A process, not a tool…
• Focus on streamlining development
• Developers integrate code into shared repository
• Each check-in is verified
• Automated builds
• Automated tests
• A feedback loop
• High visibility
• Easier & quicker to prevent and find problems,
less back tracks => short integrations
10

11. And Continuous Delivery?
• Next step after continuous integration
• Becoming lean, and even more Agile
• Make sure each change is releasable
• Develop-> build-> test-> move to staging-> acceptance test
• Build a process to release with a push of a button
• Deploy to production-> test production
• Actual deployment to production is manually
actuated
=> Ensure risk mitigation and high efficiency
11

12. Continuous Delivery Moving Ahead!
• Why is that happening?
12

13. Living in an Agile world…
• Doing better with less
• Reacting quickly to market needs
• Getting ahead of competition
• Just can’t wait 6 months for that next
release…
13
• Agile Development
• Process Automation
• DevOps

14. Dealing with Risk
 Smaller and more focused changes are easier to manage (Agile…)
 Automation of repeating tasks lowers risk of (human) error
 Development and Operations should work in synergy (DevOps)

15. Why Continuous Delivery?
15
• Rapid changes
• Reacting quickly to market needs
• Getting ahead of competition
• Fewer changes backed out
• Better collaboration
• Fewer defects
• Ultimately better service
• Happy customers
• Profitability

16. 16
This is why!

17. But…
17

18. Where is the gap?
• Why not 100%?
• 19% think it is impossible??
• What is so special about the database?
18

19. Database is a Key Component
• The database holds your essential information
• Any changes can impact the entire system
• Need to be synchronized with other changes
• Often overlooked
19

20. Reaching Inside the Database
• There is more to a database than SQL scripts
• Schema structure
• Code
• Content and meta-content
• Internal dependencies
• …
• Ensure that changes are not made without
authorization
• Ensure no out-of-process changes
20

21. The Weakest Link In a Chain
• Old adage but true
• The database is often neglected and therefore can
become the weakest link
• Essential from a compliance and business point of
21
view
• Should be the strongest link

22. Down from 81% to a HALF?
22
• Why?

23. Developers and DBAs
• Silos exist…
• Don’t always communicate effectively
• Need to share knowledge
• Need to follow same procedures & best
practices
23

24. So why not move forward?
24
• Mistrust…

25. Lets talk about Mistrust…
“it was difficult to track who made a change to a database object and
what change they made.”
(working-around file based version control)
“it took hours to get releases working. some changes were not
documented and left out…”
(manual and error prone releases)
“We had multiple releases to production every day. That is one release
a week with multiple follow up fixes, and yet more fixes”
(code overrides, partial versions, wrong versions – all pushed to production)
“We recently had a disaster - the script in the version control was not
updated and when executed in production, ran the wrong revision. That
cost tens of thousands of $”
(an out-of-process update to QA that was not properly tracked)
25

26. • Root Causes for issues:
• Manual script based version control process
• Deployment tools unaware of version control
• No release automation red-flags…
26

27. Mistrust in version control…
Version Control Process
A
27
(file based)
Development Process
Check-Out
Script
Modify Script
Get updated
Script from DB
Check-In
Script
Compile
Script
in DB
Debug Script
in DB
?
?
?
?
A’

28. Scripts & Version Control
28
Challenges…
• Code-overrides
• Working on the wrong revisions
• Scripts do not always find their way to the version control solution
• Out of process updates go unnoticed
• Hard to locate outdated update scripts
Playing safe? what we really need:
• The actual code of the object
• The upgrade script
• A roll-back script
Scripts
• Hard to test in their entirely (holistically)
• Hard to test due to colliding dependencies
• Need to run in a specific order…
• Much harder to deal with project scope changes

29. Mistrust in scripting automation…
Int QA Stage Prod
29
X
1.1234567 1.1.1
Database Deploy Script
Re-Base (due to defects)
Environment
Dev
Dev
Dev
Model
1.1 1.2
1.2 1.3
1.3 1.4
1.4 1.5
1.5 1.6
1.6 1.7
1..147 1.1
1.1 1.2
1.2 1.3
1.3 1.4
1.4 1.5
1.5 1.6
1.6 1.7
1.1 1.2
1.2 1.3
1.3 1.4
1.4 1.5
1.5 1.6
1.6 1.7
Out of Process
Change
X
X
X
X
X
? 1.1.1
X

30. Scripts are static…
Scripts, unless super sophisticated:
• Unaware of changes made in the target environment
• Time passed from their coding to the time they are run
• Potentially overriding production hot-fixes or work done in parallel by
30
another team
Content changes are very hard to manage
• Metadata & lookup content does not practically fit into the VC
• In most cases they are simply not managed

31. Traceability Coordinated Process
Impact Analysis
Gaining Trust!
31
Start in the Beginning
No Out-of-Process Changes
Automation
Task Based Development
Well Defined Processes

32. Version Control - One Enforced Process
32

33. Dealing with challenges…
Integrated Database Version Control process
• Leverage proven version control best practices
• Forcing check in & out for changes
• Labels
• etc..
• No code-overrides
• Always working with the correct revision
• All changes are documented
• Always know who did what, when, why and from where
• No out-of-process changes
• Supporting structure, code and content
No time spent on manual coding of the change scripts
33

34. 34
Bonus Points
Task based development…
• Correlate each database change with a change request
• Task ID
• Work Item
• Trouble Ticket
• CR
• etc…
…enables task based deployments
• Partial deployments (a feature, a collection of bugs, etc…)
• Scope changes easily synced between code and database

35. For deployment automation we need:
Repeatability & Safety
Using tools make sense …

36. Build & Deploy On Demand
Int QA Stage Prod
36
1.1234567
1..147 1.1 1.1
*
Database Deploy Script
* Execute the same script Environment
being executed at the
Stage environment
Re-Base (due to defects)
Dev
Dev
Dev
Model
1.1 1.2
1.2 1.3
1.3 1.4
1.4 1.5
1.5 1.6
1.6 1.7
1.1 1.4
1.4 1.7
1.1.1 1.7
File Based
Version Control
Out of Process
Change
1..17.1 1.17.1

37. Using tools
Test cases using compare & sync tools:
An index exists in source (QA) but not in target (Production)
What should we do? Add the index or not?

38. Compare & Sync tools
Safe to automate?
Sure… (?)
38

39. Deployment Automation
An index exists in Target (Production) but not in source (QA)
What should we do? Drop the index or not?

40. Compare & Sync tools
Safe to automate?
No. Requires manual inspection…
40

41. 41
Safe?
Simple, right?
NO! we are going to BREAK production without even
knowing…

42. Why break production???
A compare & sync tool:
• Is unaware of any changes that occurred before the time it ran
• Has no knowledge of changes that took place at the target environment
• Does not leverage version control for more information
• Unable to deal with conflicts & merges between different teams
• Requires manual inspection
• Requires detailed knowledge regarding each change as part of the
42
process
Mistrust AGAIN…
So…no automation… as we fear automating problems into
production and a major risk!!!

43. We need to leverage version control
into deployment decisions…
43

44. Safety Net For Deployment Automation
Simple Compare & Sync Baseline aware Analysis
Source vs.
Target
Action
= No Action
≠ ?
Source vs.
Baseline
Target vs.
Baseline
Action
= = No Action
≠ = Deploy Changes
= ≠ Protect Target
≠ ≠ Merge Changes
You do not have all
of the information
With Baselines and 3 way
analysis the unknown is
now known

45. Deploying Changes if Needed
Development Baseline
Previous Label /
Production Golden Copy
45
Production
If we had the index in the baseline =>
we should take it down from production…
(Deploy Change)

46. Or Protecting Target Environment…
Development Baseline
Previous Label /
Production Golden Copy
46
Production
BUT… If no index in baseline =>
we should protect the NEW index on production!!!
(Protect Target)

47. Deployment Automation
And Merge!!!

48. Conflict Resolving – Database Code
48

49. Conflict Resolving – Meta Data/Content
49

50. Impact Analysis
50

51. Impact Analysis! not Damage Control…
51

52. Safety Net For Deployment Automation
Database Safe Deployment Automation:
• Leverages version control (baselines & previous revisions)
• Has a flexible scope (deploy multi schema to single task or work item)
• Can be run as a batch process (repeatable & consistent)
• Integrates to ALM (labels, CRs, Continuous Integration & Delivery)
• Deals with conflicts & merges to match code agility
Can raise red flags to stop the line…
if requires human intervention
52

53. Mistrust
• Database Version control
• Database Automation
53
Awareness

54. Summary - What is DBmaestro TeamWork?
• Database Enforced Change Management solution
+ Database version control
+ Enforce best practices
+ Plugs into the ALM (change request, tickets & work items)
+ Database merge & change impact analysis
+ Know who can do what, where, when & why
• DevOps Solution for databases
+ Baseline aware deployment automation, rollback &
recovery
+ Reduce database deployment issues
+ Plugs into release management & Continuous Delivery

55. Q & A
55