kollivier / cloud-chef Goto Github PK

Currently, creating a new chef requires a series of manual steps, which include the following:

1. Creating a github repo
2. Checking out the github repo locally
3. Using cookiecutter to apply the chef template.
4. Committing the github repo
5. Adding the chef to sushibar
6. Creating the new sushibar entry, then retrieving the channel id
7. Adding the channel id, github repo, and other information to the tech specs
8. Linking the sushibar entry to the tech specs, the git repo, and the trello card
9. Using fab commands to checkout the repo on vader

Jumping between docs and copying and pasting information causes this process to take much longer than it should, and creates a lot of steps to remember. I think most of these steps could be automated using fab commands, and it would save a lot of time in new chef creation.

Also, this process creates several "sources of truth" for the state of the chef - the trello card, the tech specs doc, and the sushibar. Only the Trello card provides notifications currently (Docs does but only for comments it seems?).

Currently, each sushi chef gets its own repo, but this is problematic for a number of reasons:

1. Lack of discoverability. Has someone working on another chef done something that could make my job easier? How often have sushi chef authors duplicated effort?

2. Lack of analytics. How many chefs do we have? How much code is in them total? What are our most common types of chefs? Can we create templates for typical site types / structures? Lots of questions it's hard to answer clearly without running analytics on dozens of different repos.

3. Copy and paste issues. It's common for chefs to duplicate code. If there is a bug in this code, we have to hunt down all the copies of it and update those as well.

4. No shared issue tracking. How many total issues are open in chefs? How do we determine how to prioritize chef work? IMHO the tech specs doc should really be a github issue template.

5. Management issues. If a new sushops manager is added, do we need to setup notifications for them on all sushi-chef repos? How do they get notifications of PRs and issues? How can someone jump in and fill a need if they can't see what the needs are?

For these reasons and more, I think we should consider having a repo for our sushi chefs, with maybe a couple special exceptions for particularly involved chefs. This way a new chef would just entail creating a new subfolder, and they could still have separate venvs. (Even nicer, venvs could be a special folder in the root, so we consolidate those too.) Root folder could have special commands to do things like create a new chef using cookiecutter, setup / manage / delete its venv, and even perform cool analytics like checking what dependencies are most common and why.