[WestCoastJustin]

We just use RT [1] and TWiki [2]. Changes come in as ticket in RT [1] and we discuses them at change management meetings (document these in the TWiki [2]). We document everthing in the TWiki. If someone comes and asks for our change management policy, we point them at the TWiki, which talks about puppet, and then we can show them the change management minutes, etc. We have a light process and it seems to work.

[1] http://bestpractical.com/rt/

[2] http://twiki.org/

[rpug]

A case management system and a wiki has typically been how I have done this. It can be a little tough though because these tools aren't necessarily built for this type of workflow. Perhaps RT does a better job than some of the other options which really want to be a support ticketing system or a bug tracking system rather than a change management system.

[WestCoastJustin]

Yeah, we only have 4 people in ops and about 20 in development. We have daily standup where the ops guys and 1 person from dev meet (total 5 people). We discuss what is happening Past and Next 24 -- this takes about 10 minutes. The process is super light.

We also use puppet with git. This allows us to version everything that goes into production via a puppet tweak. This is great for rolling back changes or getting an of what was deployed. Like I said, read that visible ops handbook.

[rpug]

What about audits of user accounts and access control?