> > I'm curious to your opinion on point # 3, are you talking about OS
> packages or your organizations app version? If the latter, I was thinking
> of using hiera, maybe with a backend other than yaml such as redis, to
> store the version of the app, that way like you said it could be used in
> deploy pipeline. Why wouldn't you want to do this?
> Drew
>
Hi Drew,
I'm using a yaml backend so I can't speak about other options. So here's my
disertation on why I (mostly) don't want version numbers in hiera. In my
world view, our puppet code is just another component of our system. When
I talk about our pipeline, I'm refering to deploying a version of our
service into an environment. At the highest level, the service version
defines the version of all components - including puppet code. BTW, it's
not a big flat table, just the tip of the dependency tree.
I get my religion from Continuous Delivery (Jez Humble, David Farley) and I
can only hope that I'm not misreading it. Paraphrasing: You can break your
service much faster with a configuration change than with a code change in
one applications. So configuration should be version controlled.
The direction I'm headed is to manage top level version control outside of
our puppet code - with one caveate. We also have {%fqdn} as the first
entry in our hiera tree and the ability to override the version setting via
hiera. But it comes with the following warning:
# FQDN should only be used for temporary overrides.
Cheers,
Larry
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
