開発環境を配布する際によくやる方法をメモがてら。（なんでこうなってるのかの説明をこれで理解してもらえたら的な。）

やりたきこと

開発環境についてもGitで管理したい。
ドキュメントもGitで管理したい。
ソースのリポジトリにドキュメントや環境周りを持ちたくない。（リリース時に不必要。）
ソース・ドキュメント・環境が連動した形で管理したい
Mac・Win　プラットフォームを選ばずに簡単に環境を作れるようにしたい。

採用した方法

上記を実現させるために利用したのが「git Submodule」
親Projectを作り、各リポジトリを包括管理させることで主要コミットを連動して管理できるようにした。
また、環境に関してもDockerを利用することでローカル環境のMac・Windowsともに動かすことができ
サーバーでの結合環境までも同じ環境で確認が可能になる。

Project（親：リポジトリ）
	┣ ソース（子：サブモジュール）
	┣ ドキュメント（子：サブモジュール）
	┣ 環境（子：サブモジュール）

リリースや、デプロイの度に、親リポジトリ（Project）をCommit していく。
イメージ的には、バージョニングやGitのタグを追加するのと同じようにコミットしていく形になる。

環境部分では、Docker + docker-compose を利用して、開発環境を作成した。
親Projectから各サブモジュールを配置していれば、Dockerでマウントするディレクトリ等は
Pathがずれたりすることもなく、docker-compose up -d , docker-compose start などのコマンド一つで
環境の構築・環境を起動することができる。

下記はdocker-compose.yml のイメージ
docker 単体でつかうよりもこちらを利用することで起動オプション、設定値など様々な値がファイルで管理できる。

Project/環境/docker-compose.yml

services:

    db:
        image: mysql:5.6
        container_name: db
        hostname: db
        env_file: ./db/.env
        ports:
            - "3306:3306"
    web:
        build: ./web/
        container_name: web
        hostname: web
        volumes:
            - ../ソース:/mnt/contents/web/
        ports:
            - "80:80"
            - "443:443"
        links:
            - db

※ Mount するボリュームを相対パスで記述

        volumes:
            - ../ソース:/mnt/contents/web/

メリデメ

Git Submodule の理解・利用についての学習コストが発生する。(デメリット)
運用手順が　Git Submodule　の分だけ増えてしまう。(デメリット)
影響調査や障害の調査で、以前のバージョンの環境・ドキュメント・ソースが簡単にロールバックが可能(メリット)
各プロジェクト配下は、確実にメンバー同じ構成になっている(メリット)
Dockerを利用することで構成管理的なものがGitで行える。(メリット)
Docker-Compose を利用することで、細かいサーバー設定がGitで管理できる。(メリット)

今後の展開

本番環境もDockerによる運用を行い、Deployはコンテナのデプロイを行える環境構築をすすめる。