> > 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 puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
