In the Java enterprise world we have application servers that we deploy our applications into. An ear file is just a zip file with some metadata. its not a bad thing as such. The problematic situation occurs when we deploy our ears to our appservers. Teams start thinking that this is an unheard of problem, and invent new systems to solve this newly discovered problem. Teams might be excused since most major appservers have also invented new styles of wheels that replace basic OS functionality.
Operations people that work with servers, on the other hand, see the ears as fancy toys that they cant be bothered with, so they let the developers do their thing, then throw it away and build the thing themselves.. Notice how the operations guys didn’t get a Dev prefix. Perhaps, they might make a OS level package that they use themselves, and dont let the devs touch. when the devs express interest, the ops give condescending answers.
and ruby/python guys, dont smile smugly now. you have entirely the same issues. tried deploying your latest ruby thing on an enteprise distro much? devs swear at the ops not installing the latest stuff out of some github repo, the ops swearing at the devs and their toy code.
the real problem here is lack of communication. the devs and ops work together in the agile team, and the os level deliverable, is a joint effort.
this has many benefits that should be embarasingly obvious, but remarkably often arent. if we work out the deployment packaging early on, the entire deployment gets tested all the time, and we are sure to have an unproblematic and relaxed deploy come launch day.
Anyway, to summarize:
- as a developer, Don’t hate OS packaging such as deb:s or rpm:s.
- as an operations guy talk to the devs sometimes. They are usually nice!