Skip to content

FrOSCon - Database DevOps With Flyway, Git, Maven, MySQL And Jenkins

By Michael Hüttermann.
Thanks for the book again, i will try to write a review about it this year :-).

What Is This Talk About

  • what is a DevOp
  • the goal
  • the problem
  • the solution
  • recipes and pitfalls
  • examples - not in this documentation
  • demo (MySQL, Flyway, Jenkins, Git, Maven, Gradle, Sonar, Vagrant) - not in this documentation

How Is Part Of The Team

  • everybody how is envolved in the process of creating the software

What Is Not A DevOp

  • is already a buzz word
  • it is not a new project role
  • its also not a new tool-suite
  • devOps is not a new department / business unit
  • *

What Is A DevOp

  • development and operations
  • better communication
  • improved collaboration

The Goal

  • shared incentives
  • holistic metrics
  • common processes (like kanban)
  • shared tools (same deployment tools for development and production for example)
  • high automation degree
  • improve and accelerate delivery - downsize the batch size
    • small releases
    • downsize the changesize to keep up the frequency
    • improve the cycle time (from bug finding/feature request to release the patch/feature)

The Problem

  • a lot of completed functions/features facing a slow release cycle
    • release small, release often
  • problem between development (want feature online) against operation (want stable and "relaiable" software)

The Solution

  • value stream map
  • continuous integration
  • continuous delivery (each commit moves system into stable and releaseable version)
  • continuous deployment
  • development and operation is merged together to create a infinie loop of release and feedback (both directions)
  • share knowledge and experience

Define clearly what is a release (new feature, bugfix, and so one). Again DevOps is not a new layer between the two areas. Responsibilites is still clear to reproduce scenarios (automate as much). It is about people, not about tools. Implement culture of communication. Try to find conceptual deficits (also software design problems) as early as possible. Add a version number to your database layout (most likly same release number than code) - flyway, liquibase, self-made

The Area Matrix

  • area 1 - extend development to operations
    • practice
      • use tools like puppet/chef/cfengine to provision environments from versioned code
    • goal
      • fast feedback through automations
      • reuse of code and tools
      • reliability of delivery process and provisioning
  • area 2 - extend operations to development
    • practice
      • provide monitoring and log files to development (or automated database snapshots to reproduce bug on development machine)
    • goal
      • share information about state in production
      • enable development to improve
      • enable development to trace production incidents
  • area 3 - embed development into operations (end user experience is goal to reach)
    • practice
      • set stability and capacity as development goals
    • goal
      • align goals, share incentives
  • area 4 - embed operations into development
    • practice
      • operations gives feedback about the design of the application that is under development, early and often
    • goal
      • avoid not releaseable design

Recipes And Pitfalls

  • automate to ensure repeatability and foster collaboration (build once on a build server and release)
  • consider kanban (scrum is more for development but bad for organisation)
  • consider thorough change and config management - content management
  • track to ensure traceability (which build/release contains which tickets/bugs - artifactory)
  • monitor to support accountability (nagios and everything)
  • dashboard what you are doing (talk to each other what you are doing or what you have done)
  • use version control to ensure reproducibility (no manual tweaking after checkout)
  • consider pipelines/process from "put in feature/bugfix to release"
  • create (executable) documentation to, well, document (try to define goals and what it needs to reach it)
  • align goals and incentives of devs and ops (small cycle time)
  • ask and help, open culture of communication
  • respect your colleagues (stability against features, both leads to great user experience)