2017年3月9日木曜日

githubのorganizationアカウントのリポジトリルールを整理してみた的なお話

  • このエントリーをはてなブックマークに追加

会社に所属していて、複数人数で作業したり、複数プロジェクトを管理してるとなるとgithubを使うわけで。
だけど気づいたら煩雑になってあっちこっちにドキュメントやらwikiやらなんやらと面倒なことになるわけで。
とはいっても自分の会社はエンジニアが自分一人だからあまり関係ないけども。
でもプロジェクトは中々な数を走らせてるので整理が大変になってきたわけで。

というわけで今回はそのリポジトリの整理とかルールとかそういうところをこうまとめた的なお話をば。

■用意するリポジトリ

・company/docs
・compnay/manage
・company/projectA
 ・company/api.projectA.com
 ・company/www.projectA.com
・company/projectB
 ・company/ios.company.projectB
 ・company/www.projectB.com

■company/docs

examples/
.gitignore
README.md

これは会社に所属している人すべてが見れるリポジトリ。
README.mdに全体的なリポジトリルールの説明や、会社内のルールなどを記載。
ローカルでのディレクトリ構成例なども載せてみたりとか。
ちなみにexamplesには後述するサービス名リポジトリにおいておくdocumentなどのテンプレートを置いておくと便利。

wikiには開発用ツールの紹介など、新しい人が入ったとかそういう時にうちではこれを使ってるよみたいな情報を載せておくとよい。

■company/manage

credentials/
README.md

マネージャー権限を持つ人間のみが見れるリポジトリ。
README.mdにAWSのルート権限の情報を載せたり、ドメインレジストらのID/PWなどを記載したり。
credentialsにはAWSのルート権限のMFAのQRだったりとか情報を載せたり。

wikiは社員の評価基準とかそういうのを載せておけばいいんじゃないかと思う。

■company/projectA、company/projectB

ec2.pem
README.md

各サービス名のリポジトリ。
主な目的としてはサービスのドキュメントを載せるためだけのリポジトリ。
あとはロゴなど必要なファイルを置いておくリポジトリ。
例えばREADME.mdにMySQLのスキーマを書いたスプレッドシートへのリンクを載せたりだとか、
schemaっていうフォルダを作ってAPI Blueprintで書いたAPI情報を載せたりだとか。

wikiには使っているサービスの情報を載せる。
例えばAWSだったらAWSのページを作り、どのリージョンを使っているか、アクセスキーとかDBのホスト情報とか。

■他のリポジトリ(ドメインやバンドル毎のリポジトリ)

これらは単純にソースコードを載せましょうというリポジトリ。
ちなみにリポジトリの命名規則だけど、ドメイン名やバンドルIDにすることでわかりやすいんじゃないかと。
例えばAPIだったらapi.serviceA.comとするとか。

サービス名リポジトリが存在しているので、わざわざアカウント情報とかを載せる必要はなく、
リポジトリのREADME.mdにはデプロイの流れとか、そのリポジトリ内に関することだけ書けばいいという感じ。


ってな感じでやってあげればいくらか整理されてて使いやすいんじゃないかと。
githubの新プランだとメンバー5人までだけどリポジトリ作成数は無制限だし。
特にこのサービスだとここに情報載せておいたけど、このサービスだとこっちなの?みたいなとかも防げるはず。

ちなみにgithubのチーム機能とトピックをうまく使うことで、より整理はできるんじゃないかと。

エンジニアが自分一人しかいないけど、一人でもこういう風に整理しておくと後で見返す時に便利だったり。
ということで会社間でリポジトリルールって違うと思うけど、参考にしてもらえれば的なみたいな。

0 件のコメント:

コメントを投稿

Adsense