git_repo_organization

Git Repository Organization

2014/10/15, Green Hosue

• Convener / Facilitator

Nicolas Blanc (BlaBlaCar)

• Note taker

??? (Chef) (It's Nicolas here, and i didn't take note, so sorry for all names)

Participants

8 peoples.

Summary of Discussions

The main question was "What is the best solution: 1 big repo with all cookbooks, or 1 repo per cookbook ?"

In the assembly, we were 3 to use a big repo with all inside it, 3 to use 1 repo per cookbook, and the 2 others people were Chef's staff (And by the way one these is the REAL Note taker, please complete if you read this)

There's some advantages for using a big repo:

• First of all, everything is in one place, centralized.
• It seems that it's the preferred way of doing for sys-admin.
• You can also have a overall history of your infrastructure change
• When you change a version denpendency in more than one cookbook, you can have only 1 PR. Cons:
• Hard to maintain per cookbook branches
• Not easy to version cookbook at commit time

There's some advantage for using one repo per cookbook:

• You can maintain multiples branches for one cookbook easily
• Easy to launch unit test when committing
• Easy to update version at commit time
• It seems that it's the preferred way of doing for developers Cons:
• Can be expensive if you're paying per repo
• You have to write a script to grab all repos
• You can have to prepare more PRs when changing multiple internal cookbook dependency.

Somes use today a mix of both world: All internal cookbooks are in a big repo, and all community (external) cookbooks are managed via Berks.

Even in the multiple repository for cookbooks, Chef's staff recommend to have a repo for all of the others resources:

• environment
• databags
• roles
• nodes (but it's optionnal, as not every one use node in the git repo)

What will we do now? What needs to happen next?

Do a subversion migration ? :)