build-eng-talk

View Github Repository Open presentation in a new window

1stvamp

See all presentation from 1stvamp

build-eng-talk

0 0

build-eng-talk

On Github 1stvamp / build-eng-talk

Where Goombas Dare

Build pipelines, Release Engineering, and You

Wes Mason

@1stvamp

Who?

  • / @1stvamp
  • Online services, Canonical
  • Open source

"a sub-discipline in software engineering concerned with the compilation, assembly, and delivery of source code into finished products or other software components."

Okay, so what's a build pipeline?

{Code change} / {Release}

↓

Build steps

↓

Package

↓

Asset

↓

"Store"

↓

Deploy?

"Configuration Management"

(Agility)

  • Version control
  • Branching models
  • Mainline merging (the almighty Pull Request)

Releases

(Identifiability)

  • Versioning, tagging, commits etc.
  • v1.0.0 out today!
  • Dependencies

I don't need versions, I have revisions

  • Build once with rev 42
  • Build again with rev 42
  • Was it the same? Maybe.

Don't trust state

  • Environments change, so builds can change too
  • Build artifacts are thing
  • "Version" your build

but I just get the latest deps, k?

(Reproducibility)

  • ...
  • No, really?
  • Pinning is essential, in any environment (sorry Go!)

Configuration management is about managing change

(Consistency)

  • Tracking revisions in an SCM/VCS is great..
  • .. but what about managing those changes?

Builds

  • Builds don't need to be automated, they need to be documented.
  • ..but you may as well make automation your docs.

Continuous integration

  • Goes hand in hand with a build pipeline, but can be mutually exclusive
  • Why not?

Build artifacts

  • Golden image
  • Rusty/silver/bronze/base etc. image
  • Packages

Golden images

  • VM images
  • LXCs / Docker
  • ~ Base images ~

Packages

  • Lightweight app/process images (Docker)
  • OS level packages (deb's, rpm's)
  • Application packages

Artifact repositories

..where the hell shall I put these things?!

Release management..

..or how I learned to stop worrying and love the pipeline.

Change → Build → Test → Release

But what about continuous delivery?

  • If you automate, and have faith in your "process", why not?
  • Or do you mean continuous deployment?

Our devs know how it's built

Our ops know how it's shipped

Our QA dept know how it's tested

My build broke, but why?

Document, document, document

Further consumption

sys.exit(0)

^D

◄ ► ▲ ▼