My presentation of chef workflows given at the Chef Boston Meetup
I'm not advocating that this is the "right way" to do this. Only talking about how to use git versioning if you have a complex org structure and need separate chef orgs.
to do any one thing here. This works for us (Sonian) – it may not work for you. YMMV A good process evolves over time. What we started is not where we are today and not where we’ll be in 6 months. Ownership – set it and forget it won’t work here.
SLA’s Small changes could have large consequences. Many people making changes to branches (inside and outside our team). High velocity – many hot-fixes – limited testing – Zero Tracking. Technical Debt (An easy one to blame stuff on)
Jira Invest in cleanup of technical debt Specifically in our Git Repository Split the team into Proactive/Reactive Team Decrease distractions Increase focus – decrease context switching Introduction of myself as the “buffer” New Feature Requests Hotfixes or Sysadmin type tasks Support our Engineering and Support Team
External Sensu (https://github.com/sensu) (MIT) SCLI (https://github.com/sonian/scli) IBM Smartcloud command line tool (MIT) Mise En Place (Soon to be released with MIT license) Fog (https://github.com/fog) - Contributions to Smartcloud and VPC support. Internal Security Automation
week Dev – 1 week QA) Create Jira Story – Prioritize in next sprint unless needed now. All Chef branches need Jira stories Commit, Merge, Push, Test All Jira stories (and branches) live in QA for regression testing After QA Approval – merge to master
production. Small changes could have unintended consequences. Sets of chef cookbooks and application code (often tied together) were tested at the same time. Important to get the processes in place prior to investment in automation. Technical Debt (The scapegoat)