Skip to content

Latest commit

 

History

History
280 lines (184 loc) · 5.22 KB

index.md

File metadata and controls

280 lines (184 loc) · 5.22 KB
author-meta date-meta pagetitle url-gh url-gino-keva url-demo url-talk major-minor-patch build-metadata arrow-both arrow-left arrow-right
Wesley Yarde
November 30, 2021
How (not) to store build metadata in Git
<span style="color:MediumSeaGreen">MAJOR.MINOR.PATCH</span>
<span style="color:DodgerBlue">BUILD METADATA</span>
<span style="color:Orange;font-size:125%">⇄</span>
<span style="color:Orange;font-size:125%">⇇</span>
<span style="color:Orange;font-size:125%">⇉</span>




$pagetitle$ {data-background-image="images/devopscon.jpg" data-background-size="contain" }


DevOpsCon Munich Online
$date-meta$

What is build metadata

:::: {.element: class="fragment" data-fragment-index="1"}

Build metadata is fancy for build ID.

::::

:::: {.element: class="fragment" data-fragment-index="2"}

It identies a build and the artifacts it generates.

::::

::: notes

Artifacts could be:

  • Container
  • Package

:::

Spoiler

::: notes

  • How to store
  • How to use build metadata to create a component-based CI/CD pipeline
  • Components are built independent, each with their own artifact
  • Only rebuild what has changed

:::

$author-meta$

{width=20%}
<$url-gh$>
Senior Devops Engineer
{width=50px}

Disclaimers

This talk

  • Uses fancy words
  • Is opinionated
  • Includes a live demo

::: notes

  • Uses fancy words to make up for my lack of confidence
  • State my opinion as facts. I believe it will trigger more reaction/thinking

:::

You need a basic understanding of

  • Git
  • Containers
  • Build pipelines
  • (my) Humour

... in life!

Versioning

<style> .container{ display: grid; grid-auto-flow: column; } .col{ font-size: 80%; } </style>

::: {.container} :::: {.col .element: class="fragment" data-fragment-index="1"} $major-minor-patch$

  • Describes public API
  • Incremented manually
  • Relatively static ::::

:::: {.col .element: class="fragment" data-fragment-index="2"} $build-metadata$

  • Links artifacts to commits
  • Determined by the system
  • Changes all the time :::: :::

:::: {.element: class="fragment" data-fragment-index="3"}
Semantic Versioning 2.0.0 - https://semver.org ::::

::: notes

Versioning of Artifacts:

Major.minor.patch:

  • External

  • Stored in

    • versionInfo.json (old school)
    • Git tag

Build metadata:

  • Internal
  • Where and how to store?

:::

Why link artifacts to commits?


commit $arrow-both$ artifacts

::: notes

Two reasons; we're going to look at arrows in both directions

:::

For traceability

  • commit $arrow-left$ artifacts
  • 💤 Boring 💤

::: notes Traceability means you can always find the version of code for any artifact/release/installer/installation. In open source, this concept is not that important anymore since distribution of build output is just for convenience :::

Keep track of all moving parts

  • commit $arrow-right$ artifacts
  • Only build what changed
  • 🎈 Fun! 🎈

::: notes

Historically, not all that exciting. Every change requires a build anyway. It's fun, especially with multiple parts as will see

:::

Multiple moving parts

:::: {.element: class="fragment" data-fragment-index="1"} New feature, build 46 ::::

:::: {.element: class="fragment" data-fragment-index="2"} ::::

::: notes

Determine changes:

  • Identifies what has changed

Build:

  • Each component has an independent build, which can run in parallel
  • Also run tests for each component
  • Output is a docker container

Release:

  • Collect all containers
  • Release them

:::

Git history {data-transition="slide-in fade-out"}

Git history {data-transition="fade"}

Git history {data-transition="fade"}

Let's do IT!

  1. Where to store it
  2. How to manipulate it

1. Where?

  • In Git
  • ...but not in commits
  • Git tags?
  • Git notes!

{width=60%}

::: notes

  • Using versionInfo.json here is a very silly idea
  • Since one end of the link is a git commit, storing in git makes a lot of sense
  • A commit would be horrible; it pollutes the history and doesn't even work
  • Tags have 2 drawbacks: Explosion of tags and doesn't support concurrent use
  • Git notes are perfect!

:::

Git notes

Supplement a commit message without changing the commit itself

  • git notes add|remove|show|list
  • Stored as commits in refs/notes/

2. How?

Gino Keva - A simple Git Notes Key Value store <$url-gino-keva$>

  • Store key/values in a note
  • List key/values for a commit

::: notes

  • Implemented using event sourcing pattern
  • Create materialized view with all events

:::

Demo

End

::: {.container} :::: {} This talk
::::

:::: {} Demo
::::

:::: {} Gino Keva
:::: :::