The document discusses continuous release and the challenges it presents. Continuous release allows for very frequent releases which can complicate version tracking and root cause analysis when issues arise. It also notes that not every team or company is ready for such a rapid release cycle. The document advocates for the use of binary repositories and artifact management tools to help address these challenges and enable effective continuous release practices.

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

2. About me
 Baruch
 Developer Advocate @JFrog
> Job definition (part of):
Hang out with the DevOps guys
 @jbaruch
2

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

4. Everything *aas
The New Silver Bullet

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

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

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

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

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

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

13. How Do I Know?
 Artifactory is released
with Artifactory
 JFrog SaaS offering
> Artifactory Online
> Gradle, Grails, SpringSource,
Typesafe, Jenkins, etc.
 We build, release and
eat our own dog food
> Continuously
13

14. Here Comes Binary Repository
The Right Tool for the Job

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

16. Tooling Chain

17. In the Beginning it was…

18. Binary Repo in DevOps Ecosystem

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

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

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

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

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

24. Traceability
Why and How?

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

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

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

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

29. Evil Dependencies Resolution
 POMs deployed
with variables
> Ivy is OK
 Resolution
strategies change
over time
29

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

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

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

33. Build Server Plugin
 Build information
> Resolved and realized during the build
> Attached to the artifacts
> Uploaded with the
artifacts
Artifacts + Build Info = 4eva!!11
33

34. Demo Time!
Tracing Artifacts

35. What my friends think I do
DevOps

36. What Others Think I Do
36

37. What I Think I Do
37

38. What I Really Do
38

39. What I Really Do
39

40. What I should Do

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

42. The magic of Release
Put your repository to work

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

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

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

46. Demo time!
Release With Release Candidates

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

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

50. Releasing with Release Candidates?

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

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

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

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

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

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

57. Code time!
Plugin What?

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

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

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

61. Plugin Code
 Manipulating Version Control Systems

62. Plugin Code
 Manipulating BuildInfo object

63. Plugin Code
 Creating and replacing artifacts

64. Calling REST API With CURL
al
oc
e-l
as
le
-re
le
ad
=gr
ry
to
osi
ep
tR
rge
ta
4|
=d1
xp
pE
sna
m s=
ra
pa
/1?
le
mp
xa
i -e
lt
mu
le-
ad
gr
s e/
ea
el
oR
tT
ho
aps
sn
e/
mot
ro
/p
ild
bu
s/
gin
lu
/p
api
y/
or
act
if
rt
0/a
08
o :8
em
-d
epo
/r
:/
tp
ht
64

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

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

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

68. 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
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? Build name and number
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| versioning scheme
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 Target repository for release
71

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

73. Demo time!
Release by Snapshot Promotion

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

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