代码之家 › 专栏 › 技术社区 › Mathew

部分Git部署策略?

kohana deployment git

2

Mathew · 技术社区 · 15 年前

我需要设置一个Kohana-dev环境,允许我在不同的应用程序中充分利用共享模块/系统类。每个应用程序通常属于不同的客户机。我使用Git进行源代码管理,但是我很难想出一个干净的部署方法,使我能够只有特定于某个客户机/应用程序的开发环境的那些部分向下进入该客户机的生产环境(假设该客户机的生产环境将安装Git)。

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

客户1的生产环境:

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

sparse checkout 特性,但从维护的角度来看,它可能会导致一些问题,而且我不喜欢整个repo元数据存在于客户机的生产环境repo中的想法。

1 回复 | 直到 15 年前

1

Community CDub 8 年前

理想情况下,每个目录(app/clientapp1、app/clientapp2、public\u html/clientapp1,…)都是 子模块

即:主要项目git回购:

kohana
  - applications
  - modules
  - public_html
  - system

在其中添加子模块:

- 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

- /
  - 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

定义另一个主项目,这次用于部署
true nature of submodules )