2. About me
Jasmin Fluri
Database / Automation Engineer
Schaltstelle GmbH
Database Development
Development Process
Automation and Tooling
Continuous Integration
Continuous Delivery
Software Engineering
@jasminfluri
@jasminfluri
jasminfluri Pipelining / Provisioning
«The person that builds / fixes the
CI/CD pipeline.»
3. Why am I talking about CI/CD of relational DBs?
3
Database Engineer in a
Java Environment
First Data Mart
Project
First DWH
Project
Another DWH
Project
Automated
Provisioning of
Servers
Automated
XP -> Win7 Migration
CI/CD / Ansible / GIT /
Docker / Flyway
Manual
Deployment / SVN
Manual
Deployment / GIT
2009
2011
2012
2015
2017
2018
automated CI/CD!
automated CI/CD!
automated CI/CD!
Another DB
Project
Manual
Deployment / Git
2019
automated CI/CD!
Research Project
on DB CI/CD
2021
Finished
Research
2022
Manual
Deployment / no VCS
4. … a short story about a database
change!
4
Disclaimer
Persons and processes are fictitious.
Similarities with real projects are coincidental
and not intended.
5. In our development project…
5
… consisting of a Spring Boot
application …
…. and an Oracle database …
… work 4 developers!
6. In our development project…
6
CI/CD of the Spring Boot App
is set up consistently!
Testing is an integral part!
But it looks different with the
database...
No team member has been there
from the beginning; the code was
taken over from their
predecessors.
The skills are mainly in the
development of the Spring Boot
app.
7. In our development project…
7
... this is either tried to abstract on
the application side...
In the event of an emerging
database change ...
...or to avoid it completely!
If it is nevertheless
unavoidable...
8. In our development project…
8
The execution changes the access
logic to the application, so it must
be redeployed.
The DBA executes the script
manually!
... someone in the team must write
a migration script!
dbchange.sql
E-Mail
DBA
10. In our development project…
10
The execution changes the access
logic to the application, so it must
be redeployed.
The DBA executes the script
manually!
... someone in the team must write
a migration script!
dbchange.sql
E-Mail
DBA
SQL scripts are not
available under VCS!
Because sent by email, we do not
know exactly when the change is
made!
Manual execution leaves a
lot of room for error!
No versioned access layer, which
leads to downtime!
No regression tests on the DB side!
12. 12
… it appears that most large enterprises
actually care about minimizing application
maintenance of existing production systems.
That causes them to utilize “bad” schemas,
and generally to allow “database decay”.
– Stonebreaker et al. (2016)
If we neglect our (DB) applications, they
will disintegrate!
13. often you also hear…
"... we don't avoid DB Changes,
but we have fixed Release
Windows!"
13
15. With fixed release windows …
features that are done need to wait …
• ... this causes dependencies among features.
risk increases to deploy many features at once
• ... Releases get bigger and bigger!
Short feedback cycles are not possible!
• ... Feedback is only available at the release window.
15
16. The longer we wait, the
greater the risk of
deployment!
16
Source: https://kromatic.com/blog/the-risk-of-building-the-wrong-stuff/
Features are coupled!
Mental load of
developers increases!
Risk increases!
17. We should deliver features when
they are ready! Only in
production do we know how they
behave in reality.
17
19. What do we know about releasing software?
19
The faster your teams can make changes to your
software, the sooner you can deliver value to your
customers, run experiments, and receive valuable
feedback. State of DevOps Report 2022
20. A high level of software delivery performance requires
technical preconditions!
20
Technical capabilities build upon one another.
Continuous delivery and version control amplify each other’s
ability to promote high levels of software delivery performance.
Combining continuous delivery, loosely-coupled architecture,
version control, and continuous integration fosters software
delivery performance that is greater than the sum of its parts.
State of DevOps Report 2022
https://services.google.com/fh/files/misc/2022_state_of_devops_report.pdf
21. How is Software Delivery
Performance measured?
5 Key Metrics!
Lead Time For
Changes (low)
MTTR (low)
Change Failure Rate
(low)
Deployment
Frequency (high)
Deployment
Reliability (high)
21
23. Small changes = small risk = small impact = small feedback loops
23
Source: NYTimes – The best path to long term success is slow, simple and boring!
24. What are the positive effects of small changes?
24
Small changes have minor effects! It's easy to see all the
elements that are affected!
Small changes carry only a small risk!
Small changes can be more easily undone or corrected if
they are incorrect.
25. Goal of software releases:
We want to ship small changes
continuously to get fast and continuous
feedback!
25
37. Developer
Version Control
System
Continuous
Integration
Server
Continuous
Integration
Pipeline
Push
Trigger pipeline
on commit oder
on merge request
execute
1 - Checkout source code
2 - Build and Test of
the database
3 – System tests,
Static code analysis
and Metrics
4 – Reports and
Notifications
5 - notify
Continuous Integration
File-based
development,
generated code,
exported code
The changes
have a defined
sequence!
Builds are
always
installation of
changes!
A lot of state!!
39. Before you start building a database CI/CD pipeline you need…
Static Code
Analysis /
Linting
Automated
Tests
Everything
stored under
version
control
Database
Migration
Tool
Decoupled
Codebase
DB vs APP
39
45. The choice of your database
migration tool will affect how you
store your source code!
45
46. Passive version control
(generating or exporting code from DB)
introduces the risk that we forget to export
things that we have changed inside the DB.
46
47. The majority of people uses a mix of generating and writing
migration scripts!
47
Only 23% of
developers use a
file-based
approach!
48. In order to achieve robust
deployments, migration scripts must be
repeatable!
48
49. What happens if migration scripts are not repeatable?
Non-repeatable migration script
If it fails midway, we need a new script with the
remaining changes (and corrections). Otherwise, the
script would immediately run on error.
49
Repeatable migration script
If it fails, we change it and run it again - it will continue where
it failed and execute the remaining migrations, skip the ones
already applied.
66. Unit Testing in the application
- API Tests
- Integration Tests
- Unit Tests of Backends
Testing Tools and Frameworks
Unit Testing in the database
- Unit Tests
- Integration Tests
68. What happens when release cycles are tied to other teams (or
components)?
68
Team A
Team B
Team C
Release 1 Release 2 Release 3 Release 4
This is not Continuous Delivery!
69. Why is it important to be able to deploy changes at any time?
• We don’t want to execute deployments outside of business hours.
−Because if something goes wrong, nobody is available to help fix things.
−We deserve our free time.
• Being able to deploy continuously reduces stress inside the team.
−Deployment isn’t seen as a «special event» - as it shouldn’t be.
69
72. Coupling of release
cycles must be
eliminated!
72
Application A
DB Service XY
Infrastructure
provide
Services
consume
Services
Version 1 Version 2 Version 3
Team A
Version 4
Team B
Teams want to work independently and continuously!
73. … but the problem is … only few already have an abstraction layer!
73
🤞 64,8%
74. Now we know all preconditions to
build a CI/CD pipeline for our
database!
Let‘s see how it could be built!
85. Ressources / References
Accelerate Book
https://itrevolution.com/book/accelerate/
DORA 2022
https://cloud.google.com/blog/products/devops-sre/dora-2022-accelerate-state-of-devops-report-now-out
DORA 2021
https://services.google.com/fh/files/misc/state-of-devops-2021.pdf
The best path to long term success is slow :
https://www.nytimes.com/2017/07/31/your-money/the-best-path-to-long-term-change-is-slow-simple-and-boring.html
Martin Fowler : Continuous Integration
https://www.martinfowler.com/articles/continuousIntegration.htm
Stonebreaker – Database Decay
http://people.csail.mit.edu/dongdeng/papers/bigdata2016-decay.pdf
Dragan Stepanovic – Twitter
https://twitter.com/d_stepanovic
85