Your SlideShare is downloading. ×
The Brave New World of Continuous Release - Baruch Sadogursky
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

The Brave New World of Continuous Release - Baruch Sadogursky

593
views

Published on

While rapid release cycles provide numerous benefits for end-users and developers, it puts additional pressure on DevOps to make sure that a good application is provisioned with no mistakes. In this …

While rapid release cycles provide numerous benefits for end-users and developers, it puts additional pressure on DevOps to make sure that a good application is provisioned with no mistakes. In this session, we will look at the release process from the binaries point of view. We will explain what are the processes and the methodologies for moving your build binaries between different phases until declared production-ready. In the second part of the session, we will show how business requirements can affect release procedures. We will discuss what it takes to customize the logic of the process in the context of CI servers and binary artifacts. We will demonstrate several common release methodologies and compare the pros and cons of each one.

Published in: Technology

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
593
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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 *aasThe 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 CatsDevelopers > 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 RepositoryThe 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 PipelineSource: 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. TraceabilityWhy 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 doDevOps
  • 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 ReleasePut 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 :/ tpht 64
  • 65. Calling REST API With CURLhttp://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 CURLhttp://repo-demo:8080/ Artifactory serverartifactory/api/plugins/build/promote/snapshotToRelease/gradle-multi-example/1?params=snapExp=d14|targetRepository=gradle-release-local 66
  • 67. Calling REST API With CURLhttp://repo-demo:8080/ Artifactory serverartifactory/api/plugins/ Plugins APIbuild/promote/snapshotToRelease/gradle-multi-example/1?params=snapExp=d14|targetRepository=gradle-release-local 67
  • 68. Calling REST API With CURLhttp://repo-demo:8080/ Artifactory serverartifactory/api/plugins/ Plugins APIbuild/promote/snapshotToRelease/ Plugin namegradle-multi-example/1?params=snapExp=d14|targetRepository=gradle-release-local 68
  • 69. Calling REST API With CURLhttp://repo-demo:8080/ Artifactory serverartifactory/api/plugins/ Plugins APIbuild/promote/snapshotToRelease/Plugin namegradle-multi-example/1? Build name and numberparams=snapExp=d14|targetRepository=gradle-release-local 69
  • 70. Calling REST API With CURLhttp://repo-demo:8080/ Artifactory serverartifactory/api/plugins/ Plugins APIbuild/promote/snapshotToRelease/ Plugin namegradle-multi-example/1? Build name and numberparams=snapExp=d14| versioning schemetargetRepository=gradle-release-local 70
  • 71. Calling REST API With CURLhttp://repo-demo:8080/ Artifactory serverartifactory/api/plugins/ Plugins APIbuild/promote/snapshotToRelease/ Plugin namegradle-multi-example/1? Build name and numberparams=snapExp=d14| versioning schemetargetRepository=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