Currently, I am trying out managing all of my cookbooks via git submodules and I just want to make sure that I don't have any future issues with the way I am organizing it.
I took into consideration that from a manageability standpoint, it isn' popular to put all your repos in one basket (a single chef-repo) but I also didn't want to tell my developers that they are going to have to individually manage and pull/clone each repo before executing a chef run while testing their code (we are using berks and a chef server as well).
So the following git submodule strategy was my solution:
chef-repo < main >
├── chef-repo/LICENSE
├── chef-repo/README.md
├── chef-repo/chefignore
├── chef-repo/cookbooks
│ ├── chef-repo/cookbooks/README.md
│ ├── chef-repo/cookbooks/active-directory < submodule >
│ │ ├── chef-repo/cookbooks/active-directory/Berksfile
│ │ ├── chef-repo/cookbooks/active-directory/attributes
│ │ │ └── chef-repo/cookbooks/active-directory/attributes/default.rb
│ │ │ ├── chef-repo/cookbooks/active-directory/libraries/cmd_helper.rb
│ │ ├── chef-repo/cookbooks/active-directory/recipes
│ │ └── chef-repo/cookbooks/active-directory/resources
│ │ ├── chef-repo/cookbooks/active-directory/resources/computer.rb
│ ├── chef-repo/cookbooks/example
│ ├── chef-repo/cookbooks/java < submodule >
│ │ ├── chef-repo/cookbooks/java/Berksfile
│ │ ├── chef-repo/cookbooks/java/recipes
│ │ ├── chef-repo/cookbooks/java/templates
│ ├── chef-repo/cookbooks/redhat_subscription_manager < submodule >
│ └── chef-repo/cookbooks/windows < submodule >
├── chef-repo/data_bags
├── chef-repo/environments
├── chef-repo/roles
I know that submodules aren't real popular either, so I just went with this approach so that developers could pull & clone the entire chef-repo as a whole, but they would be committing code to the individual repos.
Is there a better approach to doing this?
Thank you :)
