La Continuous Delivery è una metodologia all’avanguardia nei processi di sviluppo software. Tuttavia, l’elevato numero di incidenti e di istanze di inattività del database sono causate da processi non aggiornati, dalla riscrittura del codice e da altri disturbi del database. Attraverso l’automazione del Database è possibile evitare questi disturbi ed errori. Visualizza le slide del webinar.

1. • Emerasoft srl
• Mission
• Vision
• Market & Solutions
Monica Burzio
Gian Giacomo Ermacora

2. Agenda
• Principi di Continuous Delivery
• Vantaggi della CD
• CD per il database?
• Database version control
• Database deployment automation
• Database impact analysis
• Stopping the CD line
• DBmaestro Demo
• Q&A
Webinar: “In Database automation we trust”
SETTEMBRE 2015

3. Chi siamo
Data di nascita: 2005
Dove siamo:
 via Po, 1 – Torino
 via del Poggio Laurentino, 118 - Roma
Creare valore per i nostri clienti
implementando soluzioni
che aumentano la produttività,
facilitando la collaborazione.
La nostra mission:

4. Alcuni clienti

5. DevOps
IoT
System & Software Engineering
Testing
ALM
SOA
Process Intelligence
Business Intelligence
Security
Digital Publishing
Training
ALM+PLM
traceability
standard compliance
collaboration
Big Data
BYOD
User Experience
Quality
Enterprise Mobility
agile
IoD
IoH
Usability
API
BPM
Continuous DeliveryContinuous Integration

6. DevOps
IoT
System & Software Engineering
Testing
ALM
SOA
Process Intelligence
Business Intelligence
Security
Digital Publishing
Training
ALM+PLM
traceability
standard compliance
collaboration
Big Data
BYOD
User Experience
Quality
Enterprise Mobility
agile
IoD
IoH
Usability
API
BPM
Continuous DeliveryContinuous Integration

7. PRESSIONI MERCATO Qualità

8. REQUISITI PROCESSI
ATTIVITÁ COLLABORAZIONE

9. DevOps
Continuous
Delivery
Continuous
Integration
Automatisation Continuous
Acceleration

10. In Database
Automation
We Trust

11. About DBmaestro
11
• The leading provider of DevOps for Database
• Database development and deployment automation

12. DevOps & CD: a must for every
company
12
▪ Every business is an IT business
▪ Customers demand that you deliver new features faster
− Agile Development
− Process Automation
− DevOps
▪ Can’t wait 6 months for that next waterfall release…
▪ If you don’t, your competitor probably will

13. 13
Continuous *what*?
Continuous Integration
Continuous Delivery
Continuous Deployment
!
?

14. What is Continuous Integration?
14
• Principles and practices
• Been around for a while
▪ Focus on streamlining development
￭ Developers integrate code into shared repository
￭ Each check-in is verified
￭ Automated builds
￭ Automated tests
￭ High visibility – a feedback loop
▪ Easier & quicker to find problems, less back tracks => short
integrations

15. And Continuous Delivery?
15
▪ 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 in manually actuated
=> Ensure risk mitigation and high efficiency

16. Continuous Delivery
16
Image from Wikipedia
Fail
Pass

17. Continuous Deployment
17
• Automating changes all the way to production
￭ Develop-> build-> test-> move to staging-> acceptance test->
deploy to production-> test production
• Makes sense for Facebook, Amazon, i.e. - for large SAAS
solutions.
￭ A/B test new features
￭ Throttle traffic to new releases etc…
▪ Not for everyone…

18. How Do I Measure Success?
18
• More rapid changes
• Fewer changes backed out
• Better collaboration
• Fewer defects
• Ultimately better service
• Happy customers
• Profitability

19. Continuous Delivery moving ahead!
19
▪ Recently Conducted DBmaestro Survey
￭ Over 350 participants

20. Why Continuous Delivery?
20

21. 21
But…
what about the database?

22. What about the database?
22

23. Down to 14% !!!
23
• Based on the questions they answered, only
14% from the ones reported doing CD for DB,
are actually performing basic CD practices!!!
• The rest are plugging the automated process
with various manual steps…
• Why?
• What is so special about the database?

24. The Weakest Link In a Chain ???
24
•Old adage but true
•The database is often neglected and therefore can
become the weakest link
•Manual processes
•Database/Code Silos exist…
•Don’t always communicate effectively
•Need to follow same procedures & best practices
•Essential from a compliance and business point of view
•Should be the strongest link

25. The Database is a constraint
25

26. CD for the database
26
• In many organizations, changes to databases are not included in the CD
picture
• Too much risk – seems to be very challenging
• Too little awareness of the packaging, deployment, promotion etc. concepts
used for application code
• Insufficient tool support for these concepts

27. Manual steps in an automated
process…
27
• At first you think: It is easy! We can handle it!
• Then your start fighting a loosing game…
• And then you have to speed up!!!

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

29. What is the problem?
29
Root Causes for issues:
– Challenging manual version control process
– Static deployments code overrides
– Dynamic deployments unaware of version control
– No release automation red-flags – don’t know when to stop the line…

30. Two isolated processes
30
Version Control Process
(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
A’
Version control repository is out of sync from the tested
database and cannot act as a Single Source of Truth

31. Scripts & version control
31
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

32. 32
86%Rate this as a risk Factor
64%
Rate this as a HIGH risk Factor

33. Scripts… Build Once Deploy Many
X
1.11.1.11.11.21.31.41.51.61.7
Int QA Stage Prod
Database Deploy Script
Environment
Re-Base (due to defects)
Dev
Dev
DevModel
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.11.11.41.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
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
a
a
33

34. Scripts are static…
34
▪ 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
▪ 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
another team

35. 35
60%of those manually building scripts have
to fix or tweak them regularly as part of a
deployment process

36. 36
89%Rate this as a risk Factor
60%
Rate this as a HIGH risk Factor

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

38. Version control:
Integrated & Enforced process
38

39. Dealing with challenges…
39
▪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
▪ No time spent on manual coding of the change scripts

40. 1.11.21.31.41.51.61.7
*
Int QA Stage Prod
Database Deploy Script
Environment
*Execute the same script being
executed at the Stage environment
Re-Base (due to defects)
Dev
Dev
DevModel
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
1.1
1.1 1.1
1.41.7
File Based
Version Control
Out of Process
Change
1.1.11.7 1.1.11.7
Validate
Build & deploy on demand
40

41. Using tools
41
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?

42. Compare & sync tools
42
Safe to automate?
Sure… (?)

43. Compare & sync tools
43
Safe to automate?
No. Requires manual inspection…

44. Challenges…
44
Compare & sync tools:
▪ Are great for finding out what is out of sync
▪ Not so great for automating deployments
▪ Requires manual inspection
▪ Requires detailed knowledge regarding each change as part of the process
▪ Is unaware of any changes that occurred before the time it ran
▪ Has no knowledge of changes that took place at the target environment
▪ Unable to deal with conflicts & merges between different teams
Mistrust AGAIN… So…no automation…
We fear for automating problems into production and a major risk!!!

45. 45
We need to leverage
knowledge from version
control

46. Safety net
46
Static script based deployment

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

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

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

50. Dealing with conflicts => merging
changes
50

51. Conflict Resolving – Meta
Data/Content
51

52. Safety Net Deployment Automation
52
￭ Raise red flags on conflicts
￭ Support out-of-process changes
￭ Utilize baseline aware analysis
￭ Understand the nature of the changes
Source vs.
Baseline
Target vs.
Baseline
Action
= = No Action
≠ = Deploy Changes
= ≠ Protect Target
≠ ≠ Merge Changes

53. Impact Analysis! not Damage Control…
53
Raise red flags to stop the line…
if requires human intervention

54. Safety Net For Deployment
Automation
54
Database Safe Deployment Automation:
• Leverage one source of truth (baselines & previous revisions)
• Flexible scope (deploy multi schema to single task or work item)
• Run as a batch process (repeatable & consistent)
• Integrates to ALM (labels, CRs, Continuous Integration & Delivery)
• Deal with conflicts & merges to match code agility
Can raise red flags to stop the line…
if requires human intervention

55. To summarize CD…
55
•Automate “everything”
•Package the deployment of database changes along with all your other application
components to give a unified picture
•Move the process upstream
•Easily promote the same package (including database changes!) from one environment to
the next, handling environment-specific differences automatically
•Create the deployment pipeline

56. 56
What is DBmaestro TeamWork?

57. What does DBmaestro offer?
57
Database Enforced Change Management solution
+Database version control – for structure & content
+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
Allows you to package, verify, deploy and promote database changes just as you would
do with application code…
putting you in a position to build a full delivery pipeline…

58. 58
Change Policy Enforcement – for Oracle

59. 59
…and MsSQL

60. 60
Impact Analysis & conflict resolution

61. 61
Database deployment automation,
Database continuous integration & delivery

62. Live Demo

63. 63
Q&A ?

64. Contenuti disponibili su:
Canale slideshare di Emerasoft
Canale Youtube Emerasoft
What’s next
Contattaci: sales@emerasoft.com @
WWWVisita il nostro sito emerasoft.com
Segui i nostri canali social

65. www.emerasoft.com
sales@emerasoft.com
Emerasoft Srl
via Po, 1 – 10124 Torino
via del Poggio Laurentino, 118 – 00144 Roma
T +39 011 0120370
T +39 06 87811323
F +39 011 3710371
Grazie…
Contatti