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● [email protected]
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
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
Top Related