1. Webcast Starts at 1:00 EDT
… no you shouldn’t be hearing anything yet
#PackageReposWebinar
1

2. We start in less than 15 min
… no you shouldn’t be hearing anything yet
#PackageReposWebinar
2

3. We start in less than 10 min
… no you shouldn’t be hearing anything yet
#PackageReposWebinar
3

4. We start in less than 5 min
… no you shouldn’t be hearing anything yet
Getting excited? I am.
#PackageReposWebinar
4

5. Package Repositories
The unsung heroes.
#PackageReposWebinar
5

6. Eric’s Bio
I’m a Lead Consultant at Urbancode
where I helps customers get the
most out of their build, deploy and
release processes. I have 9 years of
automation experience throughout
Eric Minick the application life-cycle in roles as
eric@urbancode.com
@EricMinick a developer, test automation
engineer, and support engineer. I’ve
been at the forefront of CI & CD for
7+ years
6 #PackageReposWebinar

7. Serious problems from top to bottom
• Dan, new developer: can’t compile
• Pam, experienced programmer: dealing with a
merge conflict
• Tom, tester: just had a batch of bugs rejected
• Owen, operations: dealing with a production
failure
• Cynthia, CIO: has just been informed the
organization failed an audit
7 #PackageReposWebinar

8. Agenda
• Packages and configuration management
• Traditional approaches
• Elements of a successful solution
• Recipe for adoption
8 #PackageReposWebinar

9. Agenda
• Packages and configuration management
• Traditional approaches
• Elements of a successful solution
• Recipe for adoption
9

10. Configuration management
• ITIL Definition*: “The Process responsible for
maintaining information about Configuration
Items required to deliver an IT
Service, including their Relationships.”
• Understand what we are releasing and how it
relates to everything else.
10 *Source: ITIL v3 Service Transition. 2007.

11. Lots of stuff to version
Develop / Build Runtime
source
Deployable
“Code”
3rd Party libs Builds
Sub-Projects
Internal Libs Deployment
Manifests
Middleware
Infrastructure
Config
templates
Environment
Manifests
Environment VM Images
Templates
11 #PackageReposWebinar

12. Agenda
• Packages and configuration management
• Traditional approaches
• Elements of a successful solution
• Recipe for adoption
12 #PackageReposWebinar

13. “How do I make this build work?”
• Developer attempting to build
– new developer feels the pain
• Build machine view of binaries
– magic build machine
• Dependency information comes in the form of
link errors
13 #PackageReposWebinar

14. “Use Google”
14 #PackageReposWebinar

15. “I’ll email that to you”
15 #PackageReposWebinar

16. “It’s in the lib directory”
Binary dependencies are versioned with the
source code
16 #PackageReposWebinar

17. “Go get that off the file share”
• Single source for the organization
• Dependencies are now scriptable
• Version explosion
– hard to know when to remove an old version
– hard to know which to use
17 #PackageReposWebinar

18. “I’m waiting for the internet to download”
• Using Maven Central as a binary repository
18 #PackageReposWebinar

19. Deploy & Release: almost as bad as build
19 #PackageReposWebinar

20. Agenda
• Binaries and configuration management
• Traditional approaches for dealing with
binaries
• Elements of a successful solution
• Recipe for adoption
20 #PackageReposWebinar

21. What they need
• Developers
– A description of dependencies
– Location to get them (and easy updates)
– Controlled official versions of dependencies
• QA
– What’s in my environment: A deployment manifest
• Ops
– The same manifest & everyone else’s house in order
• CIO / Audit
– Inventory of who deployed what where
21 #PackageReposWebinar

22. ITIL Definitive Media Library
• Location where the definitive and approved
versions of all software configuration items are
securely stored
• Includes:
– archive and retention periods
– environment support (e.g. test and live environments)
– tamper resistance
Service Transition, ITIL v 3; Lacy & Macfarlane;
2007
22 #PackageReposWebinar

23. Good binary management
• Package Repository
– authoritative place to store versioned binaries
– access control
– checksums for tamper resistance
– release meta-data
– retention periods
• Dependency management
– ITIL: “relationships between configuration items”
23 #PackageReposWebinar

24. Build Dependencies
• “Description of dependencies” is complex
• Requires:
– track compile time and runtime dependencies
– automated retrieval from repository
– traceable: give me a manifest
24 #PackageReposWebinar

25. Deployment Manifests
• Collection of versioned packages to deploy
• How (also versioned)
– Process
– Configuration rules
25
source: http://www.flickr.com/photos/expertinfantry/5449659589/

26. Package repos: hand off from Dev to Ops
AKA: DSL, DML, Artifact Repo, Binary Repo
26 #PackageReposWebinar

27. 27 #PackageReposWebinar

28. Agenda
• Binaries and configuration management
• Traditional approaches for dealing with
binaries
• Elements of a successful solution
• Recipe for adoption
28 #PackageReposWebinar

29. Our recommended recipe
1. The dependency audit
2. Decide who will control dependency rules
3. Decide who will control the repository
4. Establish a binary artifact repository
5. Link scripts to repository
6. Migrate dependencies to repository
7. Deny the old methods
8. Develop tested stacks
29 #PackageReposWebinar

30. Dependency Audit
• Begin researching dependency relationships
• Need to avoid breaking what we have today
• Validate files are the version they claim to be
• Requires understanding relationships between
teams and their components
• Where is there commonality? Conflicts?
30 #PackageReposWebinar

31. Decide who will control repository
• Will we have one repo or several?
• How do new 3rd party artifacts get added?
– architecture checks for duplication
– security and compliance concerns
• What internal systems can register versions?
• What policies are used for removing old
versions?
31 #PackageReposWebinar

32. Decide who will control of dependency rules
• Developers often best understand the
project’s needs
• Architects suggest components that should be
used everywhere
• CM team often set policy for what’s allowed
• QA knows what’s been tested
• Operations knows what’s approved for
production use
32 #PackageReposWebinar

33. Establish a package repository
• Select a repository
– Codestation, Maven, Yum, SCM Tool….
• Implement it
– installation
– configuration
– disaster recovery
– retention policy
– security rules
• authentication & authorization
33 #PackageReposWebinar

34. Link scripts to repository
• Build scripts
• Deployment scripts
• Provisioning scripts
• Create a “walking skeleton” for a
smooth, incremental transition
http://alistair.cockburn.us/Walking+skeleton
34 #PackageReposWebinar

35. Migrate dependencies to repository
• Shouldbe easy
• It won’t be
35 #PackageReposWebinar

36. Deny the old methods
• Turn off the file share
• Firewall off Maven Central
• Reject commits of libraries to source control
36 #PackageReposWebinar

37. Develop tested stacks
• Identify groups of components commonly
used together
• Test versions of those groups and create a
“stack” – a version of the group
• If you build your app on this stack, it will work
in our environment
– With infrastructure automation this becomes PaaS
37 #PackageReposWebinar

38. Checking in with the team
• Dan, new developer: quickly up to speed
• Pam, experienced programmer: getting work
done
• Tom, tester: not wasting time on bogus bugs
• Owen, operations: working a 40 hour work
week
• Cynthia, CIO: working on new initiatives
38 #PackageReposWebinar

39. Key Takeaways
• The package repository as a key role in your
tool chain
• Audit what you are using in this place now and
consider alternatives that are better tailored
• If it’s important, version it
39 #PackageReposWebinar

40. Package Repo bundled in our Products
• AnthillPro
– All in one continuous delivery platform
• uBuild
– Build automation and CI for the hard problems
• uDeploy
– Deployment and release management
• uProvision
– Spins up virtual environments. Integrated with
VMWare, Azure and EC2
40

41. Q&A
@UrbanCodeSoft
@EricMinick
Slideshare.net/Urbancode
41 #PackageReposWebinar