3

我在一家网络创业公司工作，我们的产品终于接近了市场。迄今为止，它几乎是靠座位飞行，所有开发人员都在 SVN 的同一个分支上工作，这没关系。但是现在我们即将发布并即将聘请 QA，我们需要开始更多地按书构建事物。我负责设计我们的 QA 和发布流程。只是，我不完全确定我应该按照什么“书”来做事。我知道有许多不同的选项可供选择，我向您求助 StackOverflowers，请您就我们所拥有的最合适的解决方案提供建议：

  • 数据库是 MS SQL Server 2008（即将是 2012）。
  • 我们计划购买RedGate 的 SQL Developer Bundle 的许可证，经过 1 周的评估，它看起来是一个非常有用的工具。
  • 服务器端代码是 C#。
  • UI 是 ASP.NET 和 Flex/Flash 的组合。
  • 我们确实有单独的服务器可用于开发、QA 和 Live。
  • 通过 SVN 进行源代码控制。

我想要的结果是一键构建并发布到 QA 的所有内容。一旦 QA 批准了它，它应该再次一键推送它。

请推荐您会做的任何事情，从如何管理代码分支到任何可以节省我们时间和金钱的第三方软件。在这个阶段，只要成本合理，我们愿意接受任何建议或改变我们做事的方式。

谢谢！

4

2 回答 2

3

只是，我不完全确定我应该按照什么“书”来做事。

一定要看看持续交付 你需要大量的自动化——在测试和部署中。工具肯定是需要的，但它们只会走这么远。所有在主干/主线上工作的开发人员都可以。长期存在的分支只会在以后增加集成挑战。参考书在这方面有很多很好的建议。全面披露：我与本书的一位作者在同一家公司工作。

于 2012-07-09T04:50:30.367 回答
2

这听起来与我们刚开始时遇到的问题非常相似。我们在组建 QA 团队时奠定的基础今天仍然存在，并且是发布过程成功的基石。

关于我们如何构建构建版本的一些高级观点

  • 我们必须在任何时候都知道代码中发生了什么以及为什么。跟踪某种错误跟踪系统中更改的意图。

  • 所有代码签入都必须引用一组已提交的工作。如果它是 QOL 增强，则有人创建票证 t 参考。没有未参考的签到！

  • 代码每天至少从头开始构建一次，最好每天多次。QA始终从最新版本进行测试。

  • 构建失败将得到最紧迫的处理；立即修复。

  • 构建必须以某种形式长期存储，并用作交付的基础。主要里程碑不仅标记在源代码控制上，而且标记在长期存储机器上。为此，我们使用了一台名为BuildManager的机器

  • 我个人不相信将部署与 QA 团队分开。我相信每个 QA 工程师都应该知道如何部署应用程序并自己创建必要的测试数据。这种方法有一些权衡，如果有兴趣，我很乐意进一步讨论

  • 部署代码后，必须运行某种健全性测试。无论是系统/配置测试，还是实际的功能验证，您都必须尽您所能确保此构建不会浪费任何人的时间。减少代码签入之间的间隔时间并知道有一个可靠的构建是您可以进行的最佳自动化投资之一。

从这里开始，QA 的结构以及他们如何与团队的其他成员合作与刚刚讨论的基础一样重要。

于 2012-07-15T19:32:59.820 回答