我在一家网络创业公司工作，我们的产品最终接近市场。到目前为止，它几乎是在裤子座位上飞行，所有开发人员都在SVN的同一分支上工作，这一切都很好。但是现在我们正在接近发布并即将招聘QA，我们需要从本书开始构建更多内容。我一直负责设计QA＆amp; amp;发布过程。只是，我不完全确定“这本书”是什么，我应该做的事情。我知道有很多不同的选择可供选择，我向您转发StackOverflowers，以获得有关我们所拥有的最合适解决方案的建议：
我想要的结果是一键式构建＆amp;向所有内容发布质量保证。一旦QA批准了它，它应该再次点击一下就可以将它推向现场。
请推荐您将要做的任何事情，从如何管理代码分支到任何能节省我们时间的第三方软件。钱。在这个阶段，我们愿意接受任何建议，或者改变我们做事的方式，只要它具有成本合理性。
谢谢！
答案 0 :(得分：3)
只是，我不完全确定我应该做的“书”是什么 事情。
请查看Continuous Delivery 在测试和部署中，您将需要大量的自动化。肯定需要工具，但它们只会到目前为止。在主干/主线上工作的所有开发人员都可以。长期分支只会在以后增加集成挑战。引用的书对此有很多好的建议。完全披露：我作为本书的作者之一为同一家公司工作。
答案 1 :(得分：2)
这听起来与我们在开始时遇到的问题非常相似。我们在构建QA团队时奠定的基础今天仍然存在，并且是发布过程成功的基石。
关于我们如何构建构建版本的一些高级别要点
我们必须始终知道代码的内容和原因。跟踪某种错误跟踪系统中的更改意图。
所有代码签到都必须引用一组已提交的工作。如果是QOL增强功能，则会有人创建故障单引用。没有未参考的登记入住！
代码至少每天从头开始构建一次，最好每天多次。 QA 始终来自最新版本的测试。
以最紧迫的态度对待构建失败;立即修复。
构建必须存储在某种长期存储中，并用作交付的基础。主要里程碑不仅标记在源控制上，而且标记在长期存储机器上。为此，我们使用名为 BuildManager 的机器
我个人不相信将部署与QA团队分开。我相信每个QA工程师都应该知道如何部署应用程序并自己创建必要的测试数据。这种方法有一些权衡，如果有兴趣，我很乐意进一步讨论
部署代码后，必须运行某种形式的健全性测试。无论是系统/配置测试还是实际功能验证，您都必须尽一切可能确保此构建不会浪费任何人的时间。减少代码签入之间的挂起时间并了解可靠的构建是您可以进行的最佳自动化投资之一。
从这里开始，QA的结构以及它们与团队其他成员的合作方式与刚才讨论的基础一样重要。