1

我们使用以下 git 工作流程在不同的开发人员团队中工作：

  1. 领取票
  2. git拉/结帐
  3. 创建功能/错误修复分支
  4. 做改变
  5. 提交到分支
  6. 合并到测试分支，git pull 到测试环境
  7. 在与 live 相同的环境中测试
  8. 如果测试成功，则合并到证明，git pull 到证明
  9. 客户签收
  10. 合并生活
  11. git pull 直播

但是，我无法决定开发人员将更改拉到实时服务器的最佳方式。

目前，开发人员通过 SSH 连接到实时服务器（使用个人用户帐户）并执行 git pull - 但是他们需要对服务器上的代码库具有读/写访问权限。

我不喜欢这样，因为只有一个人（或系统管理员）必须执行部署。

另一种方法是创建一个 Web 可访问的 git pull 脚本，因此当开发人员想要执行 pull 时，该脚本会在服务器上执行 git pull 并输出到浏览器。

在我看来，最好的替代方法是在将 repo 推送到时触发挂钩 - 我们使用 gitlab，所以我认为这个实现相对简单，web 服务器上的脚本接收一个包含有关存储库信息的 POST 对象，因此可以编写脚本，仅在接收挂钩的分支已更新时才触发拉动（如果有意义的话）。还可以向执行推送的用户发送一封电子邮件，并输出 git pull 消息，以确保一切按计划进行。但是我很不舒服开发人员可能会不小心推送到错误的分支并且提交过早地生效 - 理想情况下应该有某种 github 风格的合并请求功能。

有没有人有任何其他的建议或建议？

4

3 回答 3

1

我们喜欢使用Gerrit进行代码审查。Gerrit 实例位于中央 Git 存储库之上，让项目负责人审查内容。一旦提交被审查和接受，Jenkins CI就会启动，进行自动代码样式检查、单元测试、自动生成 API 文档等，最后使用 Apache Ant 脚本进行部署（如果所有测试都通过）。这是一个相当复杂的设置，但我们已经爱上了它。

这些很棒的教程详细介绍了设置。

于 2013-09-02T10:07:03.063 回答
1

在工作中，我们使用capistrano + webistrano。尽管它是基于 ruby​​ 的，并且许多特性都是 ruby​​ 特有的，但它可以完美地满足我们的需要。

这是我们的工作流程：

1-5：和你一样

6:去 dev webistrano -> 选择分支 -> 部署

7：客户签收等

8：去live webistrano -> 选择分支 -> 部署

它还支持部署脚本和许多其他东西。使用部署脚本，我们使用shared文件夹和current文件夹。部署脚本创建指向共享文件夹的符号链接，其中包含库和其他不在 git 存储库中的内容。

这是magento 的示例部署脚本。

Jenkins是持续集成的另一种选择。与 capistrano（自动测试执行）相比，它支持一些额外的东西，所以它可能值得一试。

于 2013-09-02T10:09:54.223 回答
0

除了您在流程中发现的问题外，我还担心并行更改会发生冲突并在您的“证明”环境中创建无效的测试。

假设 Bob 将更改 #1 拉到 Proof，然后 Dave 将更改 #2 拉到 Proof，然后客户端测试更改 #1（针对具有 #1 和 #2 的代码库），当您将更改 #1 拉到 Live 时，您有效地提取未经测试的代码。

我建议考虑不可变构建和构建工件。我的一位同事就这个主题写了一篇很好的文章。您的流程的主要变化是：

  • 1-5：（相同）
  • 6：从测试分支检索；捕获构建工件；部署构建工件进行测试
  • 7：（相同）
  • 8：促进构建到证明；部署构建工件
  • 9（相同）
  • 10促进构建生活；部署构建工件

您还应该考虑使用像 Inedo 的 BuildMaster 这样的部署/交付自动化工具。免费版应该比你需要的多，它将帮助你从“登录并运行脚本”到“在适当的批准后单击按钮”。

免责声明：我为Inedo工作

于 2013-09-02T15:23:53.450 回答