The Brave New World of Continuous Release - Baruch Sadogursky

658 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 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
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
658
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
7
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

The Brave New World of Continuous Release - Baruch Sadogursky

  1. 1. The Brave New World of Continuous Release Baruch, JFrog
  2. 2. About me Baruch Developer Advocate @JFrog > Job definition (part of): Hang out with the DevOps guys @jbaruch 2
  3. 3. Agenda The cloud silver bullet The right tool for the job Binaries all the way The magic of release 3
  4. 4. Everything *aasThe New Silver Bullet
  5. 5. What’s So Good About *aaS? *aaS features Continuous Delivery 5
  6. 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. 7. Almost, except the IT Used to quarterly release cycles “Secure” pace Minimizing the entropy caused by developers with ADD 7
  8. 8. Herding CatsDevelopers > Increasing entropy +IT (operations) > Maintaining stability =DevOps > Stable change
  9. 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. 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. 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. 12. Agile Tooling for DevOps Checklist Versioning Access control Traceability Promotions Tags and annotations Search 12
  13. 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. 14. Here Comes Binary RepositoryThe Right Tool for the Job
  15. 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. 16. Tooling Chain
  17. 17. In the Beginning it was…
  18. 18. Binary Repo in DevOps Ecosystem
  19. 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. 20. The Release PipelineSource: Agile ALM, Michael Hüttermann, Manning Publications Co.
  21. 21. Passing the software to QA Different access rights Different physical location Ability to annotate 21
  22. 22. Staging and Preproduction Replication of Production environment > Lock versions of dependencies and artifacts Allow access to set of users 22
  23. 23. Going to Production Convert staging binaries to production Allow public access Change settings Tag 23
  24. 24. TraceabilityWhy and How?
  25. 25. The Time Machine Sometimes you need to go back in time
  26. 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. 27. Rebuilding from Sources Checkout branch/tag/revision Build Done! Time consuming Unstable 27
  28. 28. Dependencies Lie Dependency Descriptors aren’t stable 28
  29. 29. Evil Dependencies Resolution POMs deployed with variables > Ivy is OK Resolution strategies change over time 29
  30. 30. Single Source of Truth Record information on spot > When binaries are created Build Server 30
  31. 31. Single Target of Truth Truth should be saved… … with the binaries… … in binaries storage! 31
  32. 32. Open Standard Of Truth Bill of Materials JSON REST accessible API accessible APLv2 on GitHub 32
  33. 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. 34. Demo Time!Tracing Artifacts
  35. 35. What my friends think I doDevOps
  36. 36. What Others Think I Do 36
  37. 37. What I Think I Do 37
  38. 38. What I Really Do 38
  39. 39. What I Really Do 39
  40. 40. What I should Do
  41. 41. Target: Automation It’s impossible to release frequently with manual procedures > While maintaining quality Use your binaries storage to release
  42. 42. The magic of ReleasePut your repository to work
  43. 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. 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. 45. Releasing With Artifactory Plugin Changes versions in build script Allows choosing a target deploy repository Creates a VCS tag/branch 45
  46. 46. Demo time!Release With Release Candidates
  47. 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. 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. 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. 50. Releasing with Release Candidates?
  51. 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. 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. 53. Controlling Versioning Scheme Classic versioning scheme: > Release version > 2.0.3 > Integration version > 2.0.4-SNAPSHOT YMMV 53
  54. 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. 55. REST == Scriptability == Automation It’s impossible to release frequently with manual procedures > While maintaining quality Use your scriptable binaries storage to release
  56. 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. 57. Code time!Plugin What?
  58. 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. 59. Community Effort https://github.com/JFrogDev/artifactory-user-plugins 59
  60. 60. Plugin Invocation Options As a response for various events > Download/Create/Delete > Login > Release Scheduled On demand 60
  61. 61. Plugin Code Manipulating Version Control Systems
  62. 62. Plugin Code Manipulating BuildInfo object
  63. 63. Plugin Code Creating and replacing artifacts
  64. 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. 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. 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. 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. 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. 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. 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. 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. 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. 73. Demo time!Release by Snapshot Promotion
  74. 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. 75. 4 Commandments of DevOps Automate everything Version everything Trace everything Report/Log/Feed back everything Designed by Jessica Allen on Dribbble.com 75

×