I'm going to presume you're referring to the act of taking a developed cookbook that's release ready and pushing it to chef servers that control production as opposed to releasing it to the community. If what you really want is the latter, I imagine there are few people more qualified to answer this question than opscode's Joshua Timberman.As for the former, there are a few approaches. Talk to your team and get an idea of what they want to do. This could easily get very long, so I'll do my best to keep it as brief as possible. These are just the ones I've done, they have different advantages and they are not the only options. Despite writing a lot of code surrounding workflow, I'm learning new (and better) ways all the time too.* Multiple chef servers and vcs branches -- this probably lines up best with chef-workflow from an "least amount of friction" standpoint (as c-w centers around the idea of having isolated chef servers for development cycles) but is not strictly necessary or the best idea. The idea is that you keep a release branch and one or more integration branches and tags, and the act of a release is merging to release, tagging HEAD and pushing the whole thing out. Trivial to automate and your vcs lets you reason pretty clearly about what's changing. Given private chef's recent changes in licensing, it would be trivial to do this without a lot of infrastructure and still keep everything in-house.* Full environment locks allow you to basically do the above on a single chef server, but the environment is responsible for maintaining the cookbook versions in use. This has other problems if you need to deal with non-versioned artifacts such as roles or databags, but is arguably the most "chef-ish" solution. This is a little more dependent on custom tooling to get right -- a cookbook resolver such as Berkshelf or Librarian is pretty important here, and I believe infochimps has some excellent tooling around determining the changes in metadata that will happen as the result of an upload. The big advantage here is the partitioning of cookbooks and metadata (something the first solution needs a lot more work to do properly) which is a big advantage for those looking to the community to deal with a lot of their infrastructure concerns. It's also a little more tolerant of one-offs simply because it will explode violently if you make no attempt to be tolerant. ;)* The third is the obvious but less desirable "push it all and let $diety sort it out", which while seeming absolutely scary is a real thing for lots of places and is close enough for government work, making this a real possibility for those who don't have a lot of energy to spend on the problem or won't see significant gains by formalizing things. Don't discount it because it's not actually a process is all I'm saying.Chef-Workflow can work well with all three of these -- largely because it mandates none of them. Your release process is your own.On Tue, Feb 12, 2013 at 3:47 AM, Torben Knerr < " target="_blank"> > wrote:Hi Erik,nice work! I have read the wiki with delight and it will definitely be on the list for my next chef project.Concerning workflow, I'm still looking for good way of handling cookbook releases and release vs. in-development version schemes. Do you have any ideas or suggestions about this as well?Cheers,TorbenOn Fri, Feb 8, 2013 at 11:32 PM, Erik Hollensbe < " target="_blank"> > wrote:
I'm pleased to announce the next major release of Chef-Workflow, 0.2.0.Chef-Workflow is a toolkit for unifying your infrastructure management with Chef. It aims to provide the tools you need to define your own workflow and testing needs with powerful, sensible defaults, with minimal dogma. The system is built as an "advanced tool for people with advanced needs", giving you what you need to coordinate an operations team around a set of in-house formal practices.It's split into 2 major components with a unifying toolkit library.* Chef-Workflow Tasklib is a suite of rake tasks and supporting rake toolkit to do common things you'd need to do with a chef server. The tasks are malleable so you can compose your own method of working within your team, and bring in optional included tasks to enhance your workflow, already integrated with the system.* Chef-Workflow Testlib is an integration testing system that fully orchestrates a network of chef managed machines and allows you to test interactions between built systems.Our Documentation is here: https://github.com/chef-workflow/chef-workflow/wikiIf you wish for more detail on the release, there's a blog post that goes into detail on the changes and there are changelogs available as well:Thanks for your time,-Erik
Archive powered by MHonArc 2.6.16.