stop sucking at building stuff!

@AutomatnMonkey

who is this guy?

● mykel alvis (@AutomatnMonkey, @mykelalvis)● sr. consultant at MomentumSI● MomentumSI is a leading IT consultancy focused on

enterprise transformation● http://www.momentumsi.com● http://www.automationmonkey.net● malvis@momentumsi.com

who are you?

● release engineering● system administration● management (?!)● software developer

five very basic terms

● artifact● signature● accessibility● delivery● MA(x)

what do we mean by "building stuff"?

● software!● but not just software● configurations of applications● configurations of systems● overloading the term "build"● build - create/compile ● release - create a unique instance● deploy - put artifact into circulation

what sort of bad stuff will we talk about?

● friction● stupid versioning● dependency mismanagement● failure to test● issues and how they don't get tracked● poor packaging● failure to deliver● errors in culture

what sort of good stuff will we talk about?

● [some] solutions● identifying some weak spots in build processes● categorizing and organizing artifacts properly● streamlining the delivery process● delivering usable artifacts out of the process● building software successfully (the short version)● good culture

bad culture

● drone-focused● uncommunicative● siloed● focused on leaving at the appointed hour● doesn't have a speedometer● accepts the status quo● liberally laced with Enterprise-level Apathy● heroes are villains

probiotics

● quality● focus on improving quality and our definition of quality● improving our speed and our ability to measure our speed● reducing defects and managing costs● elimination of apathy and increasing engagement

friction

● impediment a process● human-introduced● forgot to execute a process● required to execute a manual process● required to execute an extraneous process

lubrication

● read "Continuous Delivery", "The Phoenix Project" and "The Inmates Are Running The Asylum"

● standardize your toolset● standardize your build pipeline● design software that isn't such a special snowflake● strive to reach "stability"● automate the hell out of everything

stupid versioning tricks

● SCM revision numbers (foo-r23434.zip)● dates (bar-030409.jar)

○ Hint -> http://xkcd.com/1179/● embedded tags (baz-r3.0-jeremy.june3.rpm)● wtf format (qux.94.TGGZD.forward-first.tgz)

● seeks to identify specific revisions of software● bears similarities to tags in SCM● expresses a logical "signature" externally● should be parseable/comparable● mechanism for communicating with dependencies

versioning

semantic versioning

● http://semver.org● major.minor.patch● major change breaks api● minor change introduces backward-compatible api

change● patch does not change api● works very well with roadmaps

co-dependency issues

● don't know what they are● can't identify the directed graph for a dependency● attempt to download the internet to execute a build● don't know how to safely update them● no idea of the damage of updated dependencies● Package['ntp'] -> File['/etc/ntp.conf'] ~> Service

['ntpd']

managing dependencies

● managing dependencies is essential to stability● the transitive dependencies are also important● dependency trees degrade if not maintained● use a build tool that actually manages dependencies● use the dependency management of your tool● map the actual dependencies that you use/need● use a dependency proxy (if you can)● fully regression test when you change dependencies

red bar

● where it all really starts to break down● you implicitly pass 100% of all the tests that are never

written● also, you can make [an entirely false] claim about

passing 100% of written tests that aren't executed● it is right and good to release in 100% of cases where

you don't care about the output of the test runs

what i did to my parents patience

● conceptually, testing is great● tests routinely detect broken elements● tests only detect those things that get tested● tests don't get written● tests don't get updated

pedantic ways of fixing your failure to test

● write one easy test● write another easy test● write a third test that's not quite as easy● repeat until done

other ways to fix your failure to test

● accept that you won't have (valid/executed/any) tests● outsource it● produce targeted tests based on past issues● incentivise testing

you got issues

● prevalence● mass● codification● skill● deficiencies● targeted release

seeking help with your issues

● get the best one for your situation● use it as it was intended● artifact == project● include projects that aren't software● analyze the content of your issue tracker

how packaging goes bad

● the next place where the build process breaks down● frequently lack contextual metadata● incorrect metadata● inaccessible● difficult to track back to source/requirement

packaging

● put software in an easily manipulated "container"● formats like jar, gem, rpm, deb, module, .tgz, recipe● tools like jar, gem, rpmbuild, tar, (g)zip, dpkg● the actual step produces one or more artifacts

failure to yield

● delivery to the consumer does not occur● delivery is innocuously incorrect● delivery is potentially or passively dangerous● delivery is actively dangerous

guaranteed delivery within 30 minutes

● software and pizza should have similar SLAs● output of continuous integration● unattended deployment● automatic data-migration

how it probably looks

● code monkeys write code● code monkeys commit code● code monkeys compile code● code monkeys test on some test platform● test fail● back to coding● lather, rinse and most of all, repeat● code monkeys eventually declare success and

engage in a bout of self-aggrandizement to ops about how awesome they are

how it probably looks part deux

● ops monkeys look for notebook with deployment info● ops monkeys fail the first time● and the second time● and the third● ops monkeys call code monkeys in for a sit down● time passes● code monkey remembers a crucial step● ops monkey performs the step● ops monkeys deploy the app...success!● (ops monkey forgets to write down the step)

how it can look

● code monkeys work and commit to SCM● CI engine grabs code, builds, runs tests and notifies

code monkeys of the inevitable failure● eventually a CI build passes/artifacts deploy to a repo● ops clears an artifact for promotion● artifact deploys with its internal scripting● localized infrastructure is automatically reconfigured● code monkeys and ops monkeys attend happy hour

thank james randi it's over

fin