Package Centric Deployment, or how to package packages
This one has been in my queue for ages .. well.. 3+ months or so .. but still..
Over at dev2ops an article was posted with as title Pacakge Centric Application Release Methodology.
And it's that Application Release part which is actually the focus point.
The Application being split up in different parts where different teams have responsibility over those parts and having isolated packages for these parts is a good thing.
But you can easily confuse that naming of a package with the way a systems person looks at a pacakge, a deb , or an rpm. And then the story changes a lot.
They list the contents as a packge as follows :
What belongs in a package?
* Code: Application files executed by the runtime system. This could be compiled objects or interpreted script.
* Platform: Files that comprise the runtime layer. This is generally server software like Apache, JBoss, Oracle, etc.
* Content: Non-executed files containing information. These could be media files or static text.
* Configuration: Files defining the structure and settings of an online service. These could be files for configuring the runtime system or the application.
* Data: Files containing data or procedures for defining data. These could be database schema dumps, SQL scripts, .csv files, etc.
* Control: Configuration and procedures consumed by management frameworks
Now I`m convinced that not all of this content belongs in an RPM or Deb.
Config , Content and Data don't belong there at all.
Yet they have to be delivered as a package by the development team, we need to know what the deliverables are they have to provide us with. But on a system, if you autorize change to content or config you don't want our package management system to keep telling you it's checksums have changed.
Within the package-centric paradigm, each type of change noted above is bundled, distributed and executed via a package.
Executed ? You don't want your package management system to do this .. that's exactly what your configuration management platform isi supposed to do isn't it ?
On a systems level you really want to separate code, data and config.
So dev2ops is talking about a package from a developer point of view, which is a totally different view as the one from a sysadmin ...
Comments
#1 Kris Buytaert : I won't confuse them
I actually posted that you could easily coonfuse them .. then explained those as from a sysadmin point of view :)
#2 Damon Edwards : Don't confuse your system packages with application "packaging"
Hi Kris,
Just noticed this in a Google alert. I figured I'd weigh in, hopefully better late than never. :)
The sysadmin view of a package is often clouded by the individual features of their favorite package system. Alex's post was about looking the the underlying reasons and benefits for using packages (independent of any one system) and applying those to managing a release of an application stack.
I think you may have misunderstood that list of things that belong in packages. They don't all belong in the same package. They each belong individually in some sort of manageable package. Some could be rpms, some could be simple zips, some could be some package type you just made up... the point is that all of these types of artifacts are what comprise a complete application release. Having part of your release packaged and the rest of it moved around in some ad-hoc manner is inviting disaster. If you don't have a standardized and structured way to handle each of those artifact types (and the dependencies between them) with 100% repeatability and reliability you are going to have a very difficult time achieving scalable and reliable operations (let alone fully automate them).
And of course you want to rely on a configuration management tool to coordinate your overall change process and manage the flow of packages. The package-centric methodology is really a design principle for implementing your configuration management tooling. It's a way to think about the individual elements of change before the tools even come into play.
Read Alex's description of how a package is a "standard vehicle of change" again, and I think you'll see the design pattern in it.
Standard vehicle of change
The package serves as a vehicle of change, both as a unit of transmission between teams, but also as a standard means to affect the change within the context of the running application service. The package concept helps cope with rising complexity by encapsulating change-specific procedures and underlying tools behind the package's standard interfaces. In an object-oriented fashion, the package provides the standard interfaces and encapsulation needed to run efficient operations. Teams no longer have to understand the internal structure and procedures in order to apply another team's change.
Thanks,
Damon Edwards
http://controltier.com
http://dev2ops.org