Puppet vs "typical" release management / change management
129 views
Skip to first unread message
Steven James
Feb 4, 2014, 5:05:37 AM2/4/14
to puppet...@googlegroups.com
Hi there.
I'm look to see if anybody has any advice to share around how the implementation of Puppet affects the "typical" ITIL based release management and change management processes.
José Luis Ledesma
Feb 4, 2014, 6:27:38 AM2/4/14
to puppet...@googlegroups.com
We are currently setting up puppet in our infrastructure. We have a very enforcing change management process.
Moreover, is impossible to make changes in all the development servers at the same time, so using the standard Dev, test, pre, pro environments is not an options.
We have decided to work in noop mode, and set environments by version, I.e., our first initial configuration is environment v1. All new servers will be provisioned in v1.
Meanwhile we will create v2. And we will start to move servers from v1 to v2 using the change management process.
I don't know if there is a better approach to this problem.
Regards,
--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAB_ORUv5NbgL-L4SattZ5y5V9G0r4BHgfVx6Pd-WVp8frHcdXg%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.
Jason Antman
Feb 4, 2014, 8:11:05 AM2/4/14
to puppet...@googlegroups.com
Steve,
I'll leave it up to others to answer your question more directly, as I'm
not sure I really can - it's been a while since I worked in an ITIL
shop. What I will say, though, since inevitably *someone* will, is that
ITIL contains some good concepts and some bad ones. Overall, I'd never
work in an ITIL shop again, I find it far too restrictive and slow.
When you mentioned "the devops approach", are you referring to agile and
deploying/releasing very often? Or... something else?
In my opinion (and yes there are very smart people who feel otherwise)
ITIL is a band-aid for having poor review processes, poor testing, and
people who either don't know what they're doing or can't take
responsibility. I work in a web shop that deploys application code about
twice a day, which most of us consider to be painfully slow. We treat
Puppet as "infrastructure as code" - we make a change, have a git branch
peer-reviewed, deploy to a development server and test there (which will
ideally be automated in the future, via both rspec and server-spec, and
some tests against monitoring), assuming the tests pass we push to an
identical test environment, and if it passes there too, we push to
production.
So, to cut short the ITIL-bashing (under the assumption that you
probably didn't choose ITIL for your organization, and any more of it
will have you cursing my name), if by "devops" you meant rapid
deployment/release or even continuous deployment/release, then I'd go so
far as to say it's totally in conflict with the low-confidence,
slow-moving CAB approach of ITIL.
The other thing I should mention is that we're a pretty strong devops
shop - culturally (as is the meaning of devops) and in practice. We work
extremely closely with dev, engineers/ops are involved in all dev
tickets from the first elaboration, ops is included on most dev code
reviews and vice versa. That's probably a requirement to make things
work smoothly as I mentioned above.
-Jason
I'll leave it up to others to answer your question more directly, as I'm
not sure I really can - it's been a while since I worked in an ITIL
shop. What I will say, though, since inevitably *someone* will, is that
ITIL contains some good concepts and some bad ones. Overall, I'd never
work in an ITIL shop again, I find it far too restrictive and slow.
When you mentioned "the devops approach", are you referring to agile and
deploying/releasing very often? Or... something else?
In my opinion (and yes there are very smart people who feel otherwise)
ITIL is a band-aid for having poor review processes, poor testing, and
people who either don't know what they're doing or can't take
responsibility. I work in a web shop that deploys application code about
twice a day, which most of us consider to be painfully slow. We treat
Puppet as "infrastructure as code" - we make a change, have a git branch
peer-reviewed, deploy to a development server and test there (which will
ideally be automated in the future, via both rspec and server-spec, and
some tests against monitoring), assuming the tests pass we push to an
identical test environment, and if it passes there too, we push to
production.
So, to cut short the ITIL-bashing (under the assumption that you
probably didn't choose ITIL for your organization, and any more of it
will have you cursing my name), if by "devops" you meant rapid
deployment/release or even continuous deployment/release, then I'd go so
far as to say it's totally in conflict with the low-confidence,
slow-moving CAB approach of ITIL.
The other thing I should mention is that we're a pretty strong devops
shop - culturally (as is the meaning of devops) and in practice. We work
extremely closely with dev, engineers/ops are involved in all dev
tickets from the first elaboration, ops is included on most dev code
reviews and vice versa. That's probably a requirement to make things
work smoothly as I mentioned above.
-Jason
Gareth Rushgrove
Feb 4, 2014, 9:49:59 AM2/4/14
to puppet...@googlegroups.com
On 4 February 2014 14:11, Jason Antman <ja...@jasonantman.com> wrote:
> Steve,
>
> I'll leave it up to others to answer your question more directly, as I'm not
> sure I really can - it's been a while since I worked in an ITIL shop. What I
> will say, though, since inevitably *someone* will, is that ITIL contains
> some good concepts and some bad ones. Overall, I'd never work in an ITIL
> shop again, I find it far too restrictive and slow.
>
> When you mentioned "the devops approach", are you referring to agile and
> deploying/releasing very often? Or... something else?
>
> In my opinion (and yes there are very smart people who feel otherwise) ITIL
> is a band-aid for having poor review processes, poor testing, and people who
> either don't know what they're doing or can't take responsibility. I work in
> a web shop that deploys application code about twice a day, which most of us
> consider to be painfully slow. We treat Puppet as "infrastructure as code" -
> we make a change, have a git branch peer-reviewed, deploy to a development
> server and test there (which will ideally be automated in the future, via
> both rspec and server-spec, and some tests against monitoring), assuming the
> tests pass we push to an identical test environment, and if it passes there
> too, we push to production.
>
> So, to cut short the ITIL-bashing (under the assumption that you probably
> didn't choose ITIL for your organization, and any more of it will have you
> cursing my name), if by "devops" you meant rapid deployment/release or even
> continuous deployment/release, then I'd go so far as to say it's totally in
> conflict with the low-confidence, slow-moving CAB approach of ITIL.
>
One approach here is to move towards things being defined as Standard
> Steve,
>
> I'll leave it up to others to answer your question more directly, as I'm not
> sure I really can - it's been a while since I worked in an ITIL shop. What I
> will say, though, since inevitably *someone* will, is that ITIL contains
> some good concepts and some bad ones. Overall, I'd never work in an ITIL
> shop again, I find it far too restrictive and slow.
>
> When you mentioned "the devops approach", are you referring to agile and
> deploying/releasing very often? Or... something else?
>
> In my opinion (and yes there are very smart people who feel otherwise) ITIL
> is a band-aid for having poor review processes, poor testing, and people who
> either don't know what they're doing or can't take responsibility. I work in
> a web shop that deploys application code about twice a day, which most of us
> consider to be painfully slow. We treat Puppet as "infrastructure as code" -
> we make a change, have a git branch peer-reviewed, deploy to a development
> server and test there (which will ideally be automated in the future, via
> both rspec and server-spec, and some tests against monitoring), assuming the
> tests pass we push to an identical test environment, and if it passes there
> too, we push to production.
>
> So, to cut short the ITIL-bashing (under the assumption that you probably
> didn't choose ITIL for your organization, and any more of it will have you
> cursing my name), if by "devops" you meant rapid deployment/release or even
> continuous deployment/release, then I'd go so far as to say it's totally in
> conflict with the low-confidence, slow-moving CAB approach of ITIL.
>
Change in ITIL terminology. These are basically low-risk pre-approved
changes, ie. things that you do so often that going to a CAB isn't
needed. Traditionally changes to infrastructure would be infrequent,
scary and definitely require approval. However, if you have automated
review, testing and audit tracking procedures and are releasing
changes daily then it's perfectly possible to view these as standard
changes.
Basically lean in and learn some of the terminology. Build trust and
reduce (and talk about) risk.
Gareth
--
Gareth Rushgrove
@garethr
devopsweekly.com
morethanseven.net
garethrushgrove.com
Steven James
Feb 5, 2014, 3:06:36 AM2/5/14
to puppet...@googlegroups.com
Thanks for your input chaps....appreciated!
Steve
Steve
Reply all
Reply to author
Forward
0 new messages