Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Build Trust in Your Build-to-Deployment Flow!

2,271 views

Published on

Frequently deploying to production puts bigger pressure than before on DevOps to make sure the good, qualified application is provisioned with no mistakes. This session will explore some common pitfalls with traditional Continuous-Integration that increase risk, introduce manual input and human error, and generally make DevOps cringe before hitting the “deploy” button.

We will then demonstrate automation techniques that overcome these issues using popular tools, like Maven, Gradle, your CI server, custom scripts and a Binary Repository. Whether you are building software for the cloud or in-house, this presentation will show you how to have completely automated production builds that release applications which are fully traceable, managed and ready to be provisioned with no fear!

Published in: Technology, Business
  • Be the first to comment

Build Trust in Your Build-to-Deployment Flow!

  1. 1. Build Trust in YourBuild-to-Deployment Flow Baruch Sadogursky, JFrog
  2. 2. About me  Baruch Sadogursky  Developer Advocate @JFrog > Job definition (part of): Hang out with the DevOps guys  @jbaruchJavaOne Russia 2012 2
  3. 3. Agenda  The cloud silver bullet  The right tool for the job  Binaries all the way  The magic of releaseJavaOne Russia 2012 3
  4. 4. The New Silver BulletEVERYTHING *aaS
  5. 5. What’s So Good About *aaS?  *aaS features Continuous DeliveryJavaOne Russia 2012 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?JavaOne Russia 2012 6
  7. 7. Almost, except the IT  Used to quarterly release cycles  “Secure” pace  Minimizing the entropy caused by developers with ADDJavaOne Russia 2012 7
  8. 8. Herding Cats Developers > Increasing entropy + IT (operations) > Maintaining stability = DevOps > Stable changeJavaOne Russia 2012 8
  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 CDJavaOne Russia 2012 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 CDJavaOne Russia 2012 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?JavaOne Russia 2012 11
  12. 12. Agile Tooling for DevOps Checklist  Versioning  Access control  Traceability  Promotions  Tags and annotations  SearchJavaOne Russia 2012 12
  13. 13. How Do I Know?  JFrog SaaS offering > Artifactory Online › Gradle, Grails, SpringSo urce, Typesafe, Jenkins , etc.  We build, release and eat our own dog food > ContinuouslyJavaOne Russia 2012 13
  14. 14. The Right Tool for the JobHERE COMES BINARY REPOSITORY
  15. 15. Here Comes Binary Repository  E.g. Artifactory  Proxy  Smart storage > Much more than a passive space  Critical for CI/CD and ALMJavaOne Russia 2012 15
  16. 16. Tooling ChainJavaOne Russia 2012 16
  17. 17. Artifactory in DevOps EcosystemJavaOne Russia 2012 17
  18. 18. Meet Your Binary RepositoryDEMO TIME!
  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 builtJavaOne Russia 2012 19
  20. 20. The Release Pipeline Source: Agile ALM, Michael Hüttermann, Manning Publications Co.JavaOne Russia 2012 20
  21. 21. Passing the software to QA  Different access rights  Different physical location  Ability to annotateJavaOne Russia 2012 21
  22. 22. Staging and Preproduction  Replication of Production environment > Lock versions of dependencies and artifacts  Allow access to set of usersJavaOne Russia 2012 22
  23. 23. Going to Production  Convert staging binaries to production  Allow public access  Change settings  TagJavaOne Russia 2012 23
  24. 24. Traceability  Binaries should be traceable at every stage > Sources > Dependencies > Environment details > Tags  Where’s the information? > Version control system > Build serverJavaOne Russia 2012 24
  25. 25. Traceability with Artifactory Plugin  Adding Metadata about the build > Gathers build information > Uploads artifacts in a bulk > Uploads build information > Maintains bi-directional linksJavaOne Russia 2012 25
  26. 26. Tracing ArtifactsDEMO TIME!
  27. 27. DevOpsWHAT MY FRIENDS THINK I DO
  28. 28. What Others Think I DoJavaOne Russia 2012 28
  29. 29. What I Think I DoJavaOne Russia 2012 29
  30. 30. What I Really DoJavaOne Russia 2012 30
  31. 31. What I Really DoJavaOne Russia 2012 31
  32. 32. What I should DoJavaOne Russia 2012 32
  33. 33. Target: Automation  It’s impossible to release frequently with manual procedures > While maintaining quality  Use your binaries storage to releaseJavaOne Russia 2012 33
  34. 34. Put your repository to workTHE MAGIC OF RELEASE
  35. 35. 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 taggingJavaOne Russia 2012 35
  36. 36. 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, releaseJavaOne Russia 2012 36
  37. 37. Releasing With Artifactory Plugin  Changes versions in build script  Allows choosing a target deploy repository  Creates a VCS tag/branchJavaOne Russia 2012 37
  38. 38. Release With Release CandidatesDEMO TIME!
  39. 39. 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 toolsJavaOne Russia 2012
  40. 40. 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, releaseJavaOne Russia 2012 40
  41. 41. Releasing with Release Candidates  Process: 1. Produce and build snapshots until satisfied 3. Stage RC, check and verify 4. Once checked, releaseJavaOne Russia 2012 41
  42. 42. 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, releaseJavaOne Russia 2012 42
  43. 43. Target: Automation  It’s impossible to release frequently with manual procedures > While maintaining quality  Use your binaries storage to releaseJavaOne Russia 2012 43
  44. 44. Automation Flexibility  We Know: We Don’t Know Better  YMMV (great deal)  Write your own release logic  Pre and post build deploy hooksJavaOne Russia 2012 44
  45. 45. Flexible Release  Code your release strategy > Versioning scheme > VCS (tagging, branching, commit comments) > Promotion hook (copy/move, comments, status)  Available by RESTJavaOne Russia 2012 45
  46. 46. Controlling Versioning Scheme  Classic versioning scheme: > Release version › 2.0.3 > Integration version › 2.0.4-SNAPSHOT  YMMV > Write your own strategy for versioningJavaOne Russia 2012 46
  47. 47. Example: Promotion of Snapshots  Sometimes the build takes long time…  But that’s the silly reasonJavaOne Russia 2012 47
  48. 48. 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)JavaOne Russia 2012 48
  49. 49. Plugin What?CODE TIME!
  50. 50. Pluggable Architecture with DSLs  Artifactory is open for user plugins  Simple 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 descriptorsJavaOne Russia 2012
  51. 51. Plugin Invocation Options  As a response for various events > Download/Create/Delete > Login > Release  Scheduled  On demandJavaOne Russia 2012 51
  52. 52. Plugin Code  Manipulating Version Control SystemsJavaOne Russia 2012 52
  53. 53. Plugin Code  Manipulating BuildInfo objectJavaOne Russia 2012 53
  54. 54. Plugin Code  Creating and replacing artifactsJavaOne Russia 2012 54
  55. 55. Calling REST API With CURLJavaOne Russia 2012 55
  56. 56. 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- localJavaOne Russia 2012 56
  57. 57. 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- localJavaOne Russia 2012 57
  58. 58. 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- localJavaOne Russia 2012 58
  59. 59. 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- localJavaOne Russia 2012 59
  60. 60. 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- localJavaOne Russia 2012 60
  61. 61. 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- localJavaOne Russia 2012 61
  62. 62. 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 releaseJavaOne Russia 2012 62
  63. 63. 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)JavaOne Russia 2012 63
  64. 64. Release by Snapshot PromotionDEMO TIME!
  65. 65. 4 Commandments of DevOps  Automate everything  Version everything  Trace everything  Report/Log/Feed back everything Designed by Jessica Allen on Dribbble.comJavaOne Russia 2012 65
  66. 66. 4 Commandments of DevOps  Automate everything  Version everything  Trace everything  Report/Log/Feed back everything Designed by Jessica Allen on Dribbble.comJavaOne Russia 2012 66

×