Partial Git deployment strategy?

Question

I need to setup a Kohana dev environment that allows me to make full use of shared module / system classes across separate applications. Each application typically belonging to a different client. I use Git for source control, but am struggling to come up with a clean deployment method that will allow me to pull only those parts of the dev environment specific to a client / app down into that client's production environment (assuming that the client's production environment will have Git installed).

Dev enviroment:

- kohana
  - applications
     - clientapp1
     - clientapp2
  - modules
  - public_html
     - clientapp1
     - clientapp2
  - system
     - 3.0.1
     - 3.0.5

Client 1's production environment:

- /
 - applications
     - clientapp1
 - modules
 - public_html
     - client_app1
 - system
     - 3.0.5

Naturally, I want to have total control over each client "sub repo" as if it were an independent repo (in terms of gitignore, etc). I have seen topics that cover Git's sparse checkout feature, but it seems like it may cause a few problems down the line from a maintenance point of view, and I don't like the idea of the entire repo's metadata existing in client's production environment repo.

As you can probably tell, I'm not exactly a Git poweruser, so any suggestions / wisdom are very welcome!

Answer 1

Ideally, each of your directories (app/clientapp1, app/clientapp2, public_html/clientapp1, ...) is a submodule

I.e: main project git repo:

kohana
  - applications
  - modules
  - public_html
  - system

Where you add your submodules:

- kohana
  - applications
     - clientapp1  -> remote: /path/to/app_client1app Git repo
     - clientapp2  -> remote: /path/to/app_client2app Git repo
  - modules
  - public_html
     - clientapp1  -> remote: /path/to/pubhtml_client1app Git repo
     - clientapp2  -> remote: /path/to/pubhtml_client2app Git repo
  - system
     - 3.0.1  -> remote: /path/to/sys Git repo, tag 3.0.1
     - 3.0.5  -> remote: /path/to/sys Git repo, tag 3.0.5

The fact that you are using only submodules allows you:

- /
  - applications
     - clientapp1  -> remote: /path/to/app_client1app Git repo
  - modules
  - public_html
     - clientapp1  -> remote: /path/to/pubhtml_client1app Git repo
  - system
     - 3.0.5  -> remote: /path/to/sys Git repo, tag 3.0.5

• to define another main project, this time used for deployment
• work directly in special deployment branches within those submodules, allowing you to control their files in a client specific environment.
  (see true nature of submodules)