enterprise scale continuous delivery

Enterprise Scale Continuous Delivery

March 30th, 2016

2 Copyright 2016. Confidential – Distribution prohibited without permission

Before We Begin

▪ You will be on mute for the duration of the event

▪ 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


Agenda

▪ Continuous Delivery at enterprise scale

▪ The reasons why the database is often left behind

▪ Best practices of Continuous Delivery for modern

applications

▪ The way to achieve the optimal delivery pipeline –

including the database

▪ Q&A


Presenters

Yaniv Yehuda

CTO, Co-Founder at DBmaestro

Spent the last years raising awareness about the challenges

around database development and deployment, and how to

support database Continuous Delivery.


About DBmaestro

▪ The leading provider of DevOps for Database

▪ Simplify and automate database deployment processes in an agile

environment and reduce critical application downtime


Presenters

Andrew Phillips

VP DevOps Strategy for XebiaLabs

▪ Lots of enterprise software development on high-performance

systems

▪ Been on both sides of the “Dev…Ops” fence

▪ Active open source contributor and committer

▪ Regular Meetup, conference etc. presenter


About XebiaLabs

▪ We build software to support DevOps and Continuous Delivery at scale…

▪ …to accelerate your Business

TODO: Update to latest company intro


DevOps & CD: a must for every company

Adopters:

Ship code 40x faster

Complete those deployments 60x faster than their peers.

Have 95% fewer failures

and rollbacks

DevOps

Continuous Delivery

Time to Market


Continuous Delivery moving ahead!

▪ Recently Conducted DBmaestro Survey


What does this mean for you?

▪ Need to move towards architectures and processes that

allow changes to be made quickly and regularly

▪ But can’t afford to break things badly!

▪ Adoption of Continuous Delivery pipelines becoming more

and more well-established



▪ Need to move towards architectures and processes that

allow changes to be made quickly and regularly

▪ But can’t afford to break things badly!

▪ Adoption of Continuous Delivery pipelines becoming more

and more well-established

▪ Are you doing CD for the entire application?



▪ Many organizations only consider the application code when

talking about CD pipelines

▪ Uses established practices in packaging, verifying and

deploying new code and promoting changes from one

environment to the next



▪ Many organizations only consider the application code when

talking about CD pipelines

▪ Uses established practices in packaging, verifying and

deploying new code and promoting changes from one

environment to the next

▪ But what about your database?

Suggested handover point from AP to YY here?

Yaniv: Yes, exactly. Next slide

is mine.


Only 13% are actually performing basic CD practices for the DB!

Manual work:

cant scale, cant match CD frequency

not repeatable, prone to error

Continuous Delivery is big and getting bigger, but...

*2015 Dzone survey


What is the problem?

▪Root Causes for issues:

−Challenging manual source control process

−Static deployments code overrides and configuration drift

−Dynamic deployments tools unaware of version control

−No release automation red-flags – don’t know when to

stop the line…


File Version Control Process

Today: Two isolated processes

DB 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 is out of sync from the database and cannot act as a Single Source of Truth


90% Rate this as a risk factor, yet

72% Admit database may not be in sync with the source repository


Scripts & version control

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 upgrade script

− The actual code of the object

− A roll-back script


X 1.1 1.1.1 1.1 1.2 1.3 1.4 1.5 1.6 1.7

Int QA Stage Prod

Database Deploy Script

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.1 1.4 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

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

Challenge with static scripts…

Configuration drift…


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


Scripts are static…

▪ Scripts, unless super sophisticated:

− Unaware of changes made in the target environment – of configuration drift...

− Time passed from their coding to the time they are run

− Potentially overriding production hot-fixes or work done in parallel by 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


Comparing & Syncing

1.1 1.2 1.3 1.4 1.5 1.6 1.7

*

Int QA Stage Prod

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

1.1 1.1 1.1 1.4 1.7


1.1.1 1.7 1.1.1 1.7


Safe to automate?

Sure… (?)

Challenge with ‘Compare & Sync’


Safe to automate?

No. Requires manual inspection…

Challenge with ‘Compare & Sync’


70% of those using compare & sync tools have to review and fix the results as they can't always trust them to

automatically deploy correctly


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 process

So…no automation…

We fear for automating problems into

production and a major risk!!!

Challenges


The Solution to the challenges


Modern VC integrated DB process


Revision history

Actions

Standard IDE

Change

Management

Enforced and integrated to existing process


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


Leverage

Version control knowledge

into

Deployment decisions


1.1 1.2 1.3 1.4 1.5 1.6 1.7

*

Int QA Stage Prod

Dev Dev

Dev Model

1.1 1.2

1.2 1.3

1.3 1.4

1.1 1.7

1.1.1 1.7

1.1 1.1 1.1 1.4 1.7


1.1.1 1.7 1.1.1 1.7

Validate

1.4 1.5

1.5 1.6

1.6 1.7

Configuration Drift prevention / conflict identification and

Validated execution

1.4 1.5

1.5 1.6

1.6 1.7

OR

Baseline aware analysis

Validated execution / Build & deploy on demand

Validate


￭ Understand the nature of the changes

￭ Raise red flags on conflicts

￭ Support out-of-process changes

￭ Utilize baseline aware analysis

Safety Net Deployment Automation


If we had the index in the baseline (previous version) and no longer in Dev (i.e. - removed)

=> we should take it down from production…

(Deploy Change)

Deploying changes if needed

Development Baseline

Previous Label /

Production Golden Copy

Production


Development Baseline

Previous Label /

Production Golden Copy

Production

BUT… If no index in baseline => someone else added it to Production…

we should protect the NEW index on production!!!

(Protect Target)

Or protecting target environment…


Dealing with conflicts => merging changes


Continuous Delivery Pipeline

Define a process

Automate the process

Prevent/Alert out of process changes


Database Enforced Source Control

Enhanced Security and Regulatory Compliance

Database Merge and Build Automation

Database Release Automation

What does DBmaestro offer?


What does XL Deploy offer?

▪ Deployment Automation tool

▪ “Gets application X running in environment Y automatically”

TODO: Update with most recent product description



▪ Package the deployment of database changes along with all your other

application components to give a unified picture

▪ Easily promote the same package (including database changes!) from one

environment to the next, handling environment-specific differences automatically


What does XL Release offer?

▪ Release/pipeline orchestration tool for Continuous Delivery

▪ “Describe, execute and improve all the steps required to get your apps from development to

production”




▪ Define the entire dev-to-prod pipeline/release process to take into

account your current risk/comfort level for automated database

changes

▪ Invoke XL Deploy or DBmaestro directly to apply database changes

automatically

▪ Or add manual impact analysis/review gates if you require or prefer

additional checks

TODO: Rephrase to talk about defining the flow for all the changes (including the DB)

across all environments, i.e. make this more relevant to a

DBA



▪ Also plan & execute additional database actions such as backups,

copies etc.

▪ Easily tweak your process over time as your CD situation changes

TODO: Drop?



TODO: Update screenshot


How do DBmaestro, XL Deploy & XL Release work together?

▪ You need to be able to package, deploy and promote database

changes just like other application code to fully do CD

▪ The combination of DBmaestro, XL Deploy & XL Release allows you

to do just that


How DBmaestro, XL Deploy & XL Release work together?

▪ DBmaestro & XL Deploy: include database changes alongside your

code to give you a unified view and automation setup for deployments

▪ DBmaestro & XL Release: Define your delivery pipeline – including

the database – to give you exactly the level of automation and manual

validation that works for you by TODO: Add some

logos/screenshots here?


Useful resources

▪ About XebiaLabs:

www.xebialabs.com

www.xebialabs.com/products

▪ Stay informed:

blog.xebialabs.com

@XebiaLabs

youtube.com/xebialabs

▪ About DBmaestro:

www.DBmaestro.com

▪ Stay informed:

dbmaestro.com/blog/

@dbMaestro

linkedin.com/company/457315

TODO: Update resources

http://www.xebialabs.com/

http://www.xebialabs.com/trial

http://blog.xebialabs.com/

http://twitter.com/xebialabs

http://youtube.com/xebialabs

http://youtube.com/xebialabs

http://www.dbmaestro.com/

http://www.dbmaestro.com/blog/

http://www.dbmaestro.com/blog/

http://twitter.com/dbMaestro

https://www.linkedin.com/company/457315

https://www.linkedin.com/company/457315


Thank you!

Q & A Andrew Phillips [email protected] Yaniv Yehuda [email protected]

mailto:[email protected]

mailto:[email protected]

enterprise scale continuous delivery

Software