4

我正在与 7 个开发人员一起开发一个 Web 项目。我设置了一个 beta 盒（debian），以便我们可以在将新代码传递给暂存之前对其进行测试。

在 beta 盒子上，我设置了 Jenkins，并希望自动化合并/测试过程。我们还有一个测试套件，我想以某种方式配合它。

我应该如何使用 SVN / Jenkins 测试和运行 python web 项目？

我正在尝试制定一个好的工作流程。现在每个开发人员都在一个功能分支上工作，我在分支中运行代码，如果看起来不错，我们将其合并。

我希望开发人员登录到 beta jenkins，并告诉它从他们的功能分支构建。这是我对 Jenkins 将做的事情的计划：

  1. 确保功能分支是从主干重新建立的
  2. 确保 beta 分支与主干相同（覆盖任何合并的功能分支）
  3. 将功能分支合并到 beta 分支
  4. 杀死正在运行的服务器
  5. 启动服务器nohup python app.py &
  6. 运行测试套件python test.py
  7. 将测试数据输出到Jenkins中的开发者视图
  8. 如果任何测试失败，则恢复到分支合并之前的状态

我不确定如何处理合并冲突。此外，上述内容可能是坏的和错误的。任何意见，将不胜感激！

4

2 回答 2

3

这个问题有点太大了，无法在一个简单的帖子中回答，因此我将尝试提供一些提示和参考，就我个人的观点而言：

一些快速提示：

  • 我喜欢将开发人员分成多个分支的想法，但我会在功能分支上进行测试，并且只有在功能通过测试时才合并到 beta 分支，这样在测试之前不会进入 beta ！
  • 我会将集成步骤放入 Jenkins 之外的脚本中。使其成为源代码的一部分。这样您就可以在 Jenkins 之外快速测试脚本本身
  • 使用您最熟悉的构建系统或脚本语言，大多数步骤都可以使用任何编程语言轻松完成
  • 使脚本返回成功或失败，因此 Jenkins 可以将构建标记为失败
  • 对于合并问题，您有两种可能性
    • 要求在开发人员提交之前手动重新设置分支以进行集成，签入脚本并在需要重新设置时失败。这种方式不会发生合并错误，如果分支没有重新定位，则构建只会失败
    • 如果您宁愿允许非变基合并，则需要在合并错误时使构建失败，以便开发人员可以手动解决问题（通过在再次提交之前变基他/她的分支）

这里有一些我发现在这方面有用的书：

  • Google 如何测试软件，作者：James A. Whittaker、Jason Arbon、Jeff Carollo
  • 持续交付：通过 Jez Humble 的构建、测试和部署自动化实现可靠的软件发布

通过评论让我知道您希望拥有哪些其他内容。

于 2013-02-12T08:58:35.560 回答
3

有几件事：

  • 正如 barracel 建议的那样——使用一些 DVCS 会更方便——这样的 git 可以更好地准备在多个分支中工作。
  • 恕我直言，合并过程是您不想自动化的事情（我写这个是指“如何处理合并冲突”）。在我过去工作的工作流程中 - 合并总是由人工处理，有时需要进行某种代码审查（我不确定'如果它看起来不错'是什么意思 - 你是否只验证功能或它是如何实现的有方向吗？
  • 除了单元测试之外 - 在每次合并到 beta 分支后启动一些功能测试（Selenium）和性能测试（jmeter 或 tsung） - 这样您还将跟踪应用程序如何随着开发而变化（并可能及时做出反应 -例如，如果您会注意到登录页面期间的性能下降。
  • 这是微不足道的事情，但是在单独的分支上工作时 - 确保信息流，这样你就可以避免在不同的分支中开发相同的部分，或者在使用的解决方案/模式/库中变得矛盾。什么可能有帮助 - 发送失败的电子邮件（给失败的开发人员）和成功合并到主干后的每个人 - 所以每个人都会被通知（但确保你没有向开发人员发送垃圾邮件 - 他们会停止阅读它；）
  • 如果你真的有很多合并冲突 - 也许是时候重新考虑流程并尽量减少分支数量，有趣的阅读http://lostechies.com/derickbailey/2010/02/24/branching-strategies-the-cost-of -branching-and-merging/或抽象分支http://paulhammant.com/blog/branch_by_abstraction.html/
  • Make sure that developers are pulling and merging trunk to their branches often - it should also help with reducing conflicts, or even
  • Why not test directly on developer branches after merging from trunk? Such merged code, once again should be easy to merge back into the trunk
于 2013-02-13T10:16:15.133 回答