slides
Transcription
slides
Who Moved My Module? ® ® 1 About Me • Yoav Landman - JFrog’s CTO and Founder - Creator of the Artifactory Project - 10+ years experience in commercial enterprise build and development environments QCon London 2011 2 Agenda • Modular software development • Why manage modules • Using modules in release management - Release strategies and models - Common release issues QCon London 2011 3 Going modular http://www.flickr.com/photos/jemsweb/4363548805 QCon London 2011 4 Java modules • Java IDEs - project modules introduced circa 2004/2005 • Maven, Gradle, Ivy, Jigsaw, OSGi... • CI Servers - Cascading builds according to dependencies - Per module results • A reality QCon London 2011 5 Module key role players build environment/ tools use module system resolve shared module repositories use runtime environment manage, resolve module database QCon London 2011 6 key role players - real world compile, package... (maven, gradle, ivy +CI servers) use resolve, publish use OSGi, Jigsaw, Web Start... resolve (maven, gradle, ivy) binary repositories manage, resolve local repository/ cache QCon London 2011 7 Demo Time Meet Artifactory QCon London 2011 8 A Binary Repository • A shared place for binaries - 3rd party and local artifacts • Much more than a passive storage • Critical for CI and ALM QCon London 2011 9 What’s wrong with my... • Subversion • Apache file server/webdav • Shared file system • DVD • Disk-on-key, tape, drawer... QCon London 2011 10 Can your shared file system/VCS • • • • • • • • • QCon London 2011 Download and cache remote artifacts? Promote artifacts during release? Control licenses used in your software? Track and preserve artifacts used by CI builds? Enforce module CRUD security easily? Track changes made to artifacts? Automatically clean up integration garbage? Manage artifacts with powerful searches? Expose powerful REST API? 11 But I can always rebuild my modules from source! http://www.flickr.com/photos/a-culinary-photo-journal/3134396770 QCon London 2011 12 Rebuilding from VCS • Expensive & time consuming - Sometimes non-practical (resources) - Disaster recovery time • Dynamic - Properties, version ranges, etc. - Reliance on a specific environment QCon London 2011 13 The Artifact Repository Ecosystem ion t a l o s i build replica ti VCS onModules/Artifacts/Libraries ns o i s s n promot d e l i t u ex sb u r o e u i s o n i u t n n o c conten Remote t-filteri Repository s e ng Repositories search securit y mgm license c t. ontrol g n i k c a r t build n o i s i v o r p host & ss e c c a T RES QCon London 2011 proxy & cach metadat a and ta gging e 14 Artifactory • Advanced Binary Repository Manager • First searchable, web-driven repository manager (2006) • Over120,000 downloads (Feb 2011) • OSS, Pro & Cloud versions - jfrog.org | jfrog.com | artifactoryonline.com • Shaping the binary repository arena QCon London 2011 r e v e N ! k c a b k o o l 15 Demo Time on-boarding & searching QCon London 2011 16 Artifact Build Integration Platform http://www.flickr.com/photos/skrb/1326663872 QCon London 2011 17 Artifact Build Integration Platform #1 ® #1-1 #1-2 #3-2 #3-1 #2-2 #2 #3-3 #2-1 #3 QCon London 2011 18 Across-the-board integration QCon London 2011 19 Demo Time Build integration QCon London 2011 20 The release pipeline • Multiple steps towards declaring a release • Check points for advancing the release flow modules modules modules modules Source: Agile ALM, Michael Hüttermann, Manning Publications Co. QCon London 2011 21 The release pipeline model A B C GM Linear A Non-linear B C GM QCon London 2011 22 The release pipeline - YMMV http://www.flickr.com/photos/jaxxon/3335409285 QCon London 2011 23 Typical release issues • Picking a source/release strategy • Release build Isolation • Change release status without recompilation - Dynamic module descriptors • Avoiding license “creep” QCon London 2011 24 Source/release strategies • Release-to-branch • M2 Release plugin • Artifactory build-integration release QCon London 2011 25 Merge-to-branch trunk job#1: build/test release branch tag merge into branch job#2: build/test release tag tag a release QCon London 2011 26 Jenkins M2 release plugin 1. Check out latest VCS revision 2. Compile & test 3. Change POMs to next release version 4. Compile & test 5. Commit new POMs (!) 6. Create a VCS tag from WC 7. Change POMs to next dev version (++-SNAPSHOT) 8. Commit new POMs 9. Check out previously created VCS tag http://www.flickr.com/photos/rsdio/3642425935 10. Compile & test 11. Publish binaries to repository QCon London 2011 27 Jenkins M2 release plugin • Attempts to reuse a user-operated plugin in a CI environment - Uses separate external Maven process - Uses separate external VCS (svn auth) • No good rollback - End users may like CI’s VCS permissions QCon London 2011 28 Artifactory plugin 1. Change POMs to next release version 2. Compile & test 3. Publish binaries to repository 4. Create a VCS tag from WC 5. Change POMs to next dev version (version++-SNAPSHOT) 6. Commit new POMs QCon London 2011 29 Releasing with the Artifactory plugin • Fast • Easy automatic rollback - E.g. tag removal • Closely integrated with CI server - Reuses Maven and VCS definitions • Support for Ivy and Gradle + other CI servers in the works QCon London 2011 30 Demo Time Release & promotion QCon London 2011 31 Release build isolation • Cascading jobs - tests run longer • A downstream job may take wrong artifacts put by an upstream job • No isolation - the build integration silo is broken http://www.flickr.com/photos/sharynmorrow/5961475 QCon London 2011 32 Keeping integration private time job-a #12 job-b #4 job-a #13 job-c X ® A#12 B#4 C#2 ??? A#13 QCon London 2011 33 Isolating resolution • Deploy as many integration revs in parallel • Each build resolves only the artifacts in the build chain it is part of • Achieved with CI artifact painting and matrix params for resolution: http://.../artifactory/jfrog/app-1.0-SNAPSHOT.jar;build.root=j-1025 QCon London 2011 34 Demo Time Release isolation/private builds QCon London 2011 35 Avoiding recompilation on release Product Binaries v1.1-SNAP v1.1-SNAP v1.1-SNAP Qualified v1.1-SNAP v1.1-SNAP v1.1-SNAP v1.1-SNAP • • v1.1-SNAP A collection of release-qualified integration packages Lack of release status - • QCon London 2011 No way to express that without changing pom/ivy descriptors Resolution for packaging relies on descriptors 36 Resolution with integration versions • Ivy/Gradle - Integration revisions same as any release revision (1.0-782) - By default all dynamic versions are resolved and replaced in delivered modules - Can be used in a release package • Maven - Published artifacts can contain dynamic dependencies (SNAPSHOT or ranges) + unresolved properties - Very hard to keep reproducibility QCon London 2011 37 License “creep” • Verify no unwanted 3rd party is packaged into the release • Discover and apply license information continuously! - Information is there - Discover and act early QCon London 2011 38 License violation detection QCon London 2011 39 Demo Time Detecting license violations QCon London 2011 40 Summary • Why do we need a binary repository • Smart modules hub that plays key roles in - Continuous integration and delivery - Release management • Really changes how we work and think about binaries • Constantly evolving QCon London 2011 41 Thank you! Questions? QCon London 2011 42