Don't Suck at Building Stuff - Mykel Alvis at Puppet Camp Altanta
-
Upload
puppet-labs -
Category
Technology
-
view
1.037 -
download
0
description
Transcript of Don't Suck at Building Stuff - Mykel Alvis at Puppet Camp Altanta
Stop Sucking At Building Stuff!
@mykelalvis
who is this guy?
● Mykel Alvis (@mykelalvis)● Sr. Consultant at MomentumSI● MomentumSI is a leading IT consultancy focused on
enterprise transformation● http://www.momentumsi.com● [email protected]
who are you?
● release engineering● system administration● management (?!)● software developer
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 the artifact● release - create a unique artifact from known code● deploy - put the released 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?
● solutions● identifying the weak spots in our build processes● categorizing artifacts properly● organizing build output● streamlining the build process● delivering usable artifacts out of the build process● building software successfully (the short version)
bad culture
● drone-focused● laced with Enterprise-level Apathy● uncommunicative● siloed● focused on leaving at the appointed hour● doesn't have a speedometer● accepts the status quo● heroes are villians
culture
● 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
● impedes 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" and "The Phoenix Project"● standardize your toolset● standardize your build pipeline● design software that isn't such a special snowflake● attempt to achieve "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
dependencies
● practically every piece of software that you use is a dependency and/or has dependencies of it's own
● Package['ntp'] -> File['/etc/ntp.conf'] ~> Service['ntpd']
● managing dependencies is essential to stability● the transitive dependencies are also important● degrade if not diligently maintained
managing dependencies
● use a build system that actually manages dependencies● use the dependency management of your build system● map the actual dependencies that you use/need● use a dependency proxy (if you can)● fully regression test when you change dependencies
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
failing the test
● where it all really starts to break down● you pass 100% of all the tests that are never written● you also pass 100% of written tests that aren't executed● you can release in 100% of cases where you don't care about
the output of the test runs
testing
● conceptually, testing is great● tests routinely detect broken elements that get tested● tests don't get written● tests don't get updated
the pedantic way 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
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, puppet module, .tgz, recipe● tools like jar, gem, rpmbuild, tar, (g)zip, dpkg● the actual step produces one or more artifacts
failure to yield (results)
● delivery to the consumer does not occur● delivery is not correct● delivery is potentially 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● code monkeys eventually declare success and tell ops about
how awesome they are
how it probably looks part deux
● ops monkeys dig in a notebook to attempt deployment● ops monkeys fail the first time● and the second timeops 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 where the fail● 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