Chef Workflow and Cookbook Dependency Change Detection

We’re currently using Automate, but solely for Visibility. We’ve ignored Workflow entirely and chosen to extend the Jenkins based pipeline we already have in place designed around App Dev requirements. We’ve encountered some rough spots and we’re re-evaluating our choice to see if Workflow can smooth some of these areas out for us.

Is there any out of the box mechanism in Workflow that handles dependency change detection? By that I mean CookbookA depends on CookbokB and CookbookC. CookbookB depends on CookbookC as well. When CookbookC changes, what is the process/mechanism handles rebuilding CookbookA and CookbookB to consume the CookbookC change? It seems Chef supports a model where your dependencies can be defined loosely at build and runtime, but things like Policyfiles work to tighten this up (for good reason IMO). And Workflow also seems to operate on a model where dependencies are locked at a specific stage so that what’s deployed is what’s tested. So, assuming you’re doing some sort of dependency version locking in a pipeline of some variety, it seems you’re left with the need dependency change detection that syndicates and rebuilds the dependency graph for you. This concept seems common place in the App Dev world and I see that these concepts seem to be a cornerstone of Habitat as well.

Does Workflow have an answer for this problem?

1 Like