一种提高RAD环境中发布质量的简单方法
这里有点背景-我们是RAD开发人员的一个小团队（一个5人），负责一家大型非软件公司的内部软件开发。“内部软件”从使用MSSQL服务器作为后端的桌面.NET应用程序到在后台运行的Python脚本到MS Word文档和模板（技术之源）不等。 整个团队由全方位的人员组成，能够从用户那里获得需求，对其进行编码，对其进行测试并部署到生产中。一旦软件投入生产后，将由另一个团队负责，但是如果出现问题，通常我们很容易进行干预。 到目前为止，一切听起来不错，但是有一个问题-作为RAD团队，我们必须经常发布，而且如果没有我们发布一个或两个应用程序的新版本（也可能是脚本，更新的Word文档），就没有一天可做，C ++控制台应用等）导入生产环境。我们进行开发测试，并通过允许最终用户在UAT环境中运行软件来使其参与。 ...但是这些错误反正逐渐渗透到生产中。用户确实知道这些错误和偶尔的不稳定是他们为真正迅速获得所需付出的代价，但与此同时，它也让我们思考-也许我们可以改进开发或发布实践以提高稳定性。软件，并减少添加新功能时引入的错误数量。 优点-首先我们真的没有太多的流程，所以应该很容易就可以开始进行改进，不好的事情-作为RAD小组的一员，我们实际上没有太多的时间和资源来实施事情有些大，但我们一直在考虑以下举措，欢迎您提出任何反馈，提示，提示和建议。 当前，一些应用程序是在开发人员测试后直接发布到产品中的，而绕过了用户验收测试。应该停止这种做法，即使是很小的更改也必须由最终用户进行测试。每个应用程序都会有一个从最终用户中选择的专用beta测试器。仅在Beta测试人员确定新版本之后，它才能从测试环境升级到生产环境。 我们不进行代码审查-但是我们将在其中一位签入变更集之前开始进行代码审查。我也在考虑“发布审核”-基本上，一个开发人员必须坐在旁边，而另一位开发人员则看着他/她进行软件发布（复制二进制文件，更新配置，向数据库添加新表等）-通常它只是需要5到10分钟，因此不会花费太多的“发布审核”时间。 当一个新版本被证明具有足够的bug可以从生产中撤出并由一个好的旧版本替代时，如何减少回滚时间。我们确实存储了所有发行版本的历史记录（以二进制文件的形式），以使返回一个版本变得容易-尽管快速“用先前版本的二进制文件覆盖新发行的二进制文件”还是很容易的，但它仍然是一个手动过程，容易出错有时要求“如果回滚将失败并且将使系统无法使用而不是出现故障，该怎么办”。 这是我们用完我们的想法的地方，我们希望得到您的反馈，如果您可以分享一些简单的发行/开发过程改进建议，那就太好了。