The document discusses the concept of continuous release using a binary repository. It begins by outlining some of the advantages of continuous delivery for both users and developers. It then discusses some of the challenges that continuous delivery poses for operations teams who are used to more infrequent release cycles. The rest of the document focuses on how a binary repository like Artifactory can help address these challenges by enabling traceability between code and released binaries, flexible release automation through its REST API and support for plugins, and management of access rights and versions for artifacts in development, staging and production environments.

1. The Brave New World of
Continuous Release
Baruch, JFrog

2. About me
 Baruch
 Developer Advocate @JFrog
> Job definition (part of):
@jbaruch
2

3. About me
 Developer Advocate @JFrog
 Job definition:
> Hang out with
the DevOps guys
> Talk about it
 github.com/jbaruch
 @jbaruch
3

4. Agenda
 The cloud silver bullet
 The right tool for the job
 Binaries all the way
 The magic of release
4

5. EVERYTHING *aaS
The New Silver Bullet

6. What’s So Good About *aaS?
 *aaS features Continuous Delivery
6

7. Continuous Delivery FTW
 User advantages
> Latest version/features
> No upgrades/maintenance
 Developer advantages
> Agile
> Rapid feedback
> Users are the best beta-testers
> No long-term support
 Everybody wins?
7

8. Almost, except the IT
 Used to quarterly release cycles
 “Secure” pace
 Minimizing the entropy caused by
developers with ADD
8

9. Herding Cats
Developers
> Increasing entropy
+
IT (operations)
> Maintaining stability
=
DevOps
> Stable change
9

10. Continuous Delivery Challenge
 Very frequent releases
 More than one version in production
 Complicated access levels
 Root cause analysis
> Tracing from binaries to source
 Version tracking
 Not everyone is ready for CD
10

11. Continuous Delivery Challenge
 Very frequent releases
 More than one version in production
 Complicated access levels
 Root cause analysis
> Tracing from binaries to source
 Version tracking
 Not everyone is ready for CD
11

12. It’s… Agile!
 Agile principles applied for DevOps
 We have good tooling for Agile
development
> Version control
> Unit testing and code coverage
> CI servers
> Hot swap tools
 What’s up with tooling for agile DevOps?
12

13. Agile Tooling for DevOps Checklist
 Versioning
 Access control
 Traceability
 Promotions
 Tags and
annotations
 Search
13

14. Recursive Slide with Baby Photo
 Artifactory is released
with Artifactory
 JFrog SaaS offering
> Artifactory Online
› Gradle, Grails, SpringSou
rce, Typesafe, Jenkins, e
tc.
 We build, release and
eat our own dog food
> Continuously
14

15. HERE COMES BINARY REPOSITORY
The Right Tool for the Job

16. Here Comes Binary Repository
 E.g. Artifactory
 Proxy
 Smart storage
> Much more than a passive space
 Critical for CI/CD and ALM
16

17. Tooling Chain
17

18. In the Beginning it was…
18

19. Binary Repo in DevOps Ecosystem
19

20. Binaries All the Way
 From some point product in your
lifecycle, all you care about is binaries
 Lots of things to do after the software is
built
20

21. The Release Pipeline
Source: Agile ALM, Michael Hüttermann, Manning Publications Co.
21

22. Passing the software to QA
 Different access rights
 Different physical location
 Ability to annotate
22

23. Staging and Preproduction
 Replication of Production environment
> Lock versions of dependencies and artifacts
 Allow access to set of users
23

24. Going to Production
 Convert staging binaries to production
 Allow public access
 Change settings
 Tag
24

25. TRACEABILITY
Why and How?

26. The Time Machine
 Sometimes you need to go back in time

27. Quest for Traceability
 What should be restored?
> Sources
> Dependencies
> Environment details
> Tags
 Where’s the information?
> Version control system
> Build Tool
> Build server
27

28. Rebuilding from Sources
 Checkout branch/tag/revision
 Build
 Done!
 Time consuming
 Unstable
28

29. Dependencies Lie
 Dependency Descriptors aren’t stable
29

30. Evil Dependencies Resolution
 POMs deployed
with variables
> Ivy is OK
 Resolution
strategies change
over time
> Both Ivy and Maven
30

31. Single Source of Truth
 Record information on spot
> When binaries are created
 Build Server
31

32. Single Target of Truth
 Truth should be saved…
 … with the binaries…
 … in binaries storage!
32

33. Open Standard Of Truth
 Bill of Materials
 JSON
 REST accessible
 API accessible
 APLv2 on GitHub
33

34. Build Server Plugin
 Build information
> Resolved and realized during
the build
> Attached to the artifacts
> Uploaded with the
artifacts
34

35. DEMO TIME!
Tracing Artifacts

36. WHAT MY FRIENDS THINK I DO
DevOps

37. What Others Think I Do
37

38. What I Think I Do
38

39. What I Really Do
39

40. What I Really Do
40

41. What I should Do
41

42. Target: Automation
 It’s impossible to release frequently with
manual procedures
> While maintaining quality
 Use your binaries storage to release
42

43. THE MAGIC OF RELEASE
Put your repository to work

44. Release Candidates
 Your next build is a release-candidate
 Once successfully built and tested, click
the button
> Automatic versions switch
› From integration to release
> Right place to put your binaries
› Move from Staging to Public
> Automatic VCS tagging
44

45. Releasing with Release Candidates
 Process:
1. Produce and build snapshots until satisfied
2. Once satisfied, build a release candidate
3. Stage RC, check and verify
4. Once verified, release
45

46. Releasing With Artifactory Plugin
 Changes versions in build script
 Allows choosing a target deploy
repository
 Creates a VCS tag/branch
46

47. DEMO TIME!
Release With Release Candidates

48. OOTB Release Management
 Pros  Cons
> Out of the box > Limited
> Supports the “by extensibility
the book” > May not fit your
release cycle requirements
> Supports
majority of the
tools
48

49. Releasing with Release Candidates
 Process:
1. Produce and build snapshots until satisfied
2. Once satisfied, build a release candidate
3. Stage RC, check and verify
4. Once checked, release
49

50. Releasing with Release Candidates
 Process:
1. Produce and build snapshots until satisfied
3. Stage RC, check and verify
4. Once checked, release
50

51. Releasing with Release Candidates?
51

52. Releasing with Release Candidates?
 Lots of things can go wrong during one
more build
 If we won’t build it, we won’t screw it
 Revised Process:
1. Produce and build snapshots until satisfied
2. When satisfied, check and verify
3. Once checked, release
52

53. Automation Flexibility
 We Know: We Don’t Know Better
 YMMV (great deal)  Write your own
release logic
 Pre and post
build deploy
hooks
53

54. Controlling Versioning Scheme
 Classic versioning scheme:
> Release version
› 2.0.3
> Integration version
› 2.0.4-SNAPSHOT
 YMMV
54

55. Flexible Release
 Code your release strategy
> Versioning scheme
> VCS (tagging, branching, commit comments)
> Promotion hook
(copy/move, comments, status)
 Available by REST
55

56. REST == Scriptability == Automation
 It’s impossible to release frequently with
manual procedures
> While maintaining quality
 Use your scriptable binaries storage to
release
56

57. Example: Promotion of Snapshots
 Choose existing build to become a
release
 Using REST API without build server
 Invoke promotion plugin
> Convert to next version
> Tag, branch, etc.
> Promote (copy/move)
57

58. CODE TIME!
Plugin What?

59. Pluggable Architecture with DSLs
 Artifactory is open for user plugins
 Groovy groovy DSL
 Your code runs inside the server
 Uses Public API (PAPI)
> Search for artifacts
> Search for builds
> Copy/move artifacts
> Manipulate files
› E.g. change versions in descriptors
59

60. Community Effort
 https://github.com/JFrogDev/artifactory-user-plugins
60

61. Plugin Invocation Options
 As a response for various events
> Download/Create/Delete
> Login
> Release
 Scheduled
 On demand
61

62. Plugin Code
 Manipulating Version Control Systems
62

63. Plugin Code
 Manipulating BuildInfo object
63

64. Plugin Code
 Creating and replacing artifacts
64

65. Calling REST API With CURL
65

66. Calling REST API With CURL
http://repo-demo:8080/
artifactory/api/plugins/
build/promote/snapshotToRelease/
gradle-multi-example/1?
params=snapExp=d14|
targetRepository=gradle-release-
local
66

67. Calling REST API With CURL
http://repo-demo:8080/ Artifactory server
artifactory/api/plugins/
build/promote/snapshotToRelease/
gradle-multi-example/1?
params=snapExp=d14|
targetRepository=gradle-release-
local
67

68. Calling REST API With CURL
http://repo-demo:8080/ Artifactory server
artifactory/api/plugins/ Plugins API
build/promote/snapshotToRelease/
gradle-multi-example/1?
params=snapExp=d14|
targetRepository=gradle-release-
local
68

69. Calling REST API With CURL
http://repo-demo:8080/ Artifactory server
artifactory/api/plugins/ Plugins API
build/promote/snapshotToRelease/
Plugin name
gradle-multi-example/1?
params=snapExp=d14|
targetRepository=gradle-release-
local
69

70. Calling REST API With CURL
http://repo-demo:8080/ Artifactory server
artifactory/api/plugins/ Plugins API
build/promote/snapshotToRelease/Plugin name
gradle-multi-example/1? Build name and number
params=snapExp=d14|
targetRepository=gradle-release-
local
70

71. Calling REST API With CURL
http://repo-demo:8080/ Artifactory server
artifactory/api/plugins/ Plugins API
build/promote/snapshotToRelease/ Plugin name
gradle-multi-example/1? Build name and number
params=snapExp=d14| versioning scheme
targetRepository=gradle-release-
local
71

72. Calling REST API With CURL
http://repo-demo:8080/ Artifactory server
artifactory/api/plugins/ Plugins API
build/promote/snapshotToRelease/ Plugin name
gradle-multi-example/1? Build name and number
params=snapExp=d14| versioning scheme
targetRepository=gradle-release-
local Target repository for release
72

73. Recap: Promotion of Snapshots
 Choose existing build to become a
release
 Using the REST API without building
 Invoking the promotion plugin
> Convert to next version
> Tag, branch, etc.
> Promote (copy/move)
73

74. DEMO TIME!
Release by Snapshot Promotion

75. 4 Commandments of DevOps
 Automate
everything
 Version
everything
 Trace everything
 Report/Log/Feed
back everything
75

76. 4 Commandments of DevOps
 Automate
everything
 Version
everything
 Trace everything
 Report/Log/Feed
back everything Designed by Jessica Allen on Dribbble.com
76