×
  • Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
 

Automated Java Deployments With Rpm

by Freelance Linux Build, Deployment & Release Consultant, Devops advocate, Infrastructure as Code Hacker and keen Judoka at Uncommon Sense Consulting on Oct 28, 2011

  • 19,136 views

Using the RPM Maven Plugin to package Java Artefacts for fun and profit.

Using the RPM Maven Plugin to package Java Artefacts for fun and profit.

Statistics

Views

Total Views
19,136
Views on SlideShare
18,288
Embed Views
848

Actions

Likes
39
Downloads
208
Comments
7

10 Embeds 848

http://agile.dzone.com 518
http://uncommonsense-uk.com 152
http://blog.nikedev.com 139
http://paper.li 11
http://a0.twimg.com 8
http://java.dzone.com 7
http://www.linkedin.com 6
http://www.techgig.com 5
http://search.daum.net 1
http://164.135.49.40 1
More...

Accessibility

Upload Details

Uploaded via SlideShare as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

17 of 7 previous next Post a comment

  • actionjackx Martin Jackson, Freelance Linux Build, Deployment & Release Consultant, Devops advocate, Infrastructure as Code Hacker and keen Judoka at Uncommon Sense Consulting @ChrisCarroll2, Yes there's probably a lot, I still think we should always tokenize the build. I'm not so married to the use Maven to explode the WARs into RPM's though after I found the unpackWARs='false' feature in tomcat and married that with md5 finger printing.
    Since I do more Continuous Delivery work these days I'm typical more interested in using the CI system build number as the version number of any deployable package.
    I've also become a proponent of better automated testing and always rolling forward since I find that idea of rolling back is becoming less desirable and sometimes impossible (re: schema changes).
    1 year ago
    Are you sure you want to
    Your message goes here
    Processing…
  • ChrisCarroll2 Chris Carroll, Agile Software Developer & Technical Architect So if you're still interested in this a year later ...
    I take 2 main ideas from this (1) that yum & package managers are already solved the deploy/rollback/version problems years ago so why on earth wouldn't we use them and (2) tokenise configs for environment.
    Is that about right? And is there anything you'd do differently a year later?
    1 year ago
    Are you sure you want to
    Your message goes here
    Processing…
  • actionjackx Martin Jackson, Freelance Linux Build, Deployment & Release Consultant, Devops advocate, Infrastructure as Code Hacker and keen Judoka at Uncommon Sense Consulting @dserodio The configuration files are kept in puppet and the java application needs to support external configuration in order to allow this to be easily done. 1 year ago
    Are you sure you want to
    Your message goes here
    Processing…
  • dserodio dserodio Are the config files only in Puppet, or are they also in the RPM? In case they're not in the RPM, how do you exclude them? 1 year ago
    Are you sure you want to
    Your message goes here
    Processing…
  • actionjackx Martin Jackson, Freelance Linux Build, Deployment & Release Consultant, Devops advocate, Infrastructure as Code Hacker and keen Judoka at Uncommon Sense Consulting We actually do put the settings into our puppet configuration maybe it wasn't clear in the presentation (I'm planning on moving to Hiera as well).
    The initial problem was because the environment was not externalized and they were shipped with just the development parameters, deployments were problematic i.e. we could not guarantee that the application would work consistently without puppet being running twice.
    2 years ago
    Are you sure you want to
    Your message goes here
    Processing…
  • bryanwb Bryan Berry It seems like it would be easier to put the settings for your application in puppet’s hiera or in chef-server’s repository. Then you could use the maven exec plugin to execute knife (or hiera’s equivalent) to get those settings and enumerate the necessary java properties during the build process

    You do describe other advantages or rpms, such as versioning and rollback, that my fix does not offer.
    2 years ago
    Are you sure you want to
    Your message goes here
    Processing…
  • schlomo Schlomo Schapiro, Systems Architect / Open Source Evangelist at ImmobilienScout24 We do something similar and will be talking about it at the Velocity Europe (http://velocityconf.com/velocityeu/public/schedule/detail/21669). Hope to see you there and also at http://veubof2011.eventbrite.co.uk/.

    The main difference is that we use Maven to build the RPM and then we use Nexus to store the artifacts that Maven creates, both WAR and RPM.

    We wrote a Nexus YUM plugin that allows direct access to the RPMs hosted on the Nexus as a YUM repo thereby eliminating additional copying steps in our delivery chain.
    2 years ago
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Automated Java Deployments With Rpm Automated Java Deployments With Rpm Presentation Transcript