This document discusses improving processes for building and delivering software. It identifies common problems like poor testing, versioning issues, dependency mismanagement and failure to deliver. It provides solutions like standardizing tools and processes, automating tasks, managing dependencies properly, focusing on quality and reducing apathy. The goal is establishing good culture and practices to build software successfully through continuous delivery.

1. stop sucking at building stuff!
@AutomatnMonkey

2. 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

3. who are you?
● release engineering
● system administration
● management (?!)
● software developer

4. five very basic terms
● artifact
● signature
● accessibility
● delivery
● MA(x)

5. 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

6. 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

7. 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

8. 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

9. 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

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

11. 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

12. 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)

13. ● 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

14. 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

15. 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']

16. 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

17. 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

18. 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

19. 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

20. 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

21. you got issues
● prevalence
● mass
● codification
● skill
● deficiencies
● targeted release

22. 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

23. 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

24. 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

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

26. guaranteed delivery within 30 minutes
● software and pizza should have similar SLAs
● output of continuous integration
● unattended deployment
● automatic data-migration

27. 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

28. 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)

29. 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

30. thank james randi it's over
fin