On 4 February 2014 14:11, Jason Antman <[email protected]> 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 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 > 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 > > > On 02/04/2014 05:05 AM, Steven James wrote: >> >> 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. >> >> From a change perspective, I'm thinking that the whole risk thing >> associate with the CAB for example, should get a whole lot better as a >> result of version controlled infrastructure manifests, ability to provide >> infrastructure code diffs, noop runs against bare metal, with the option of >> running a few noop runs against current patch set...will probably help. >> >> How else does the ITIL base change process have to typically (er) >> change...to accommodate the devops approach? >> >> Similar question for release management. How does the introduction of >> Puppet typically affect the release management process? >> >> Any input greatly appreciated. >> >> SteveJames >> -- >> 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 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. > > > -- > 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 view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-users/52F0E6E9.5040309%40jasonantman.com. > > For more options, visit https://groups.google.com/groups/opt_out. -- Gareth Rushgrove @garethr devopsweekly.com morethanseven.net garethrushgrove.com -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAFi_6yLTvrymqbvCAMcLMz_VbiiB7JWiqeOrpbu4wqsu9xXPBA%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
