一种提高RAD环境中发布质量的简单方法

这里有点背景-我们是RAD开发人员的一个小团队（一个5人），负责一家大型非软件公司的内部软件开发。“内部软件”从使用MSSQL服务器作为后端的桌面.NET应用程序到在后台运行的Python脚本到MS Word文档和模板（技术之源）不等。

整个团队由全方位的人员组成，能够从用户那里获得需求，对其进行编码，对其进行测试并部署到生产中。一旦软件投入生产后，将由另一个团队负责，但是如果出现问题，通常我们很容易进行干预。

到目前为止，一切听起来不错，但是有一个问题-作为RAD团队，我们必须经常发布，而且如果没有我们发布一个或两个应用程序的新版本（也可能是脚本，更新的Word文档），就没有一天可做，C ++控制台应用等）导入生产环境。我们进行开发测试，并通过允许最终用户在UAT环境中运行软件来使其参与。

...但是这些错误反正逐渐渗透到生产中。用户确实知道这些错误和偶尔的不稳定是他们为真正迅速获得所需付出的代价，但与此同时，它也让我们思考-也许我们可以改进开发或发布实践以提高稳定性。软件，并减少添加新功能时引入的错误数量。

优点-首先我们真的没有太多的流程，所以应该很容易就可以开始进行改进，不好的事情-作为RAD小组的一员，我们实际上没有太多的时间和资源来实施事情有些大，但我们一直在考虑以下举措，欢迎您提出任何反馈，提示，提示和建议。

1. 当前，一些应用程序是在开发人员测试后直接发布到产品中的，而绕过了用户验收测试。应该停止这种做法，即使是很小的更改也必须由最终用户进行测试。每个应用程序都会有一个从最终用户中选择的专用beta测试器。仅在Beta测试人员确定新版本之后，它才能从测试环境升级到生产环境。

2. 我们不进行代码审查-但是我们将在其中一位签入变更集之前开始进行代码审查。我也在考虑“发布审核”-基本上，一个开发人员必须坐在旁边，而另一位开发人员则看着他/她进行软件发布（复制二进制文件，更新配置，向数据库添加新表等）-通常它只是需要5到10分钟，因此不会花费太多的“发布审核”时间。

3. 当一个新版本被证明具有足够的bug可以从生产中撤出并由一个好的旧版本替代时，如何减少回滚时间。我们确实存储了所有发行版本的历史记录（以二进制文件的形式），以使返回一个版本变得容易-尽管快速“用先前版本的二进制文件覆盖新发行的二进制文件”还是很容易的，但它仍然是一个手动过程，容易出错有时要求“如果回滚将失败并且将使系统无法使用而不是出现故障，该怎么办”。

这是我们用完我们的想法的地方，我们希望得到您的反馈，如果您可以分享一些简单的发行/开发过程改进建议，那就太好了。

+1可触及出色的主题。当我们执行“经常发布早期发布”的开发路线时，事情会按照实际步伐发展，并且随着势头的增强，会出现许多此类问题（如您所述），否则我们将不准备好应对这些问题。最让人恐惧的是，人们将速度视为做好工作的敌人。

我看到的文献很少，但是，这是我们的实践绝对可以帮助的：

1.有效的Bug跟踪
使Bug跟踪更加有效-我们要做的不仅是保留错误列表和刻度线，而且当关闭时，我们必须定义某些事情，例如“问题是否可以重现？”，“这是一个永久性的解决方案。或工作修复？”，“麻烦的根本原因是什么？” 这使您可以了解上次看到此错误时发生的情况。这是确保错误不会经常重复的关键。

2.定义关键的回退点
我们都知道错误会到来，因此我们需要提供最有效的回退点。我们一次又一次地敲定一个最常见的发行版（在我们的案例中，比率为十分之一），该发行版可以最可靠的方式在任何地方使用。发布的总数可以很多，但是如果有任何问题，回退选择的次数很少，您不必再回退。了解最佳回退的最简单方法之一就是查看哪个最早的发行版在生产中运行时间最长，而没有太多问题。

3.区分风险高的，稳定的或小的bug修复版本
当我们知道我们对算法进行了重大更改时，在并非所有可以预见的场景中，bug都可能会潜入。在某些情况下，问题很小（或很好理解）并且风险很小。难道不是俱乐部这样的功能在同一个版本的简单错误。始终首先修复一个较小的错误，该错误必须在任何需要的地方进行。最好为特殊功能集专门发布一个版本，您可以弃用该功能，但是所有其他重要的bug仍然可以在以前的版本中修复。

4.进行重要功能开发
的分支必须将对具有设计影响的更改进行关联的所有事情都在分支上分别进行。与较小的bug相比，较大的开发无法很快完成。如果我们引入中间提交，而与功能相关的“部分”工作仍未使用，则是潜在的错误引入区域；如果该功能的全部工作可以原子完成，则不会出现这些错误-因此这些是我们无需解决是否存在分支的错误。

5.始终计划基于主题的发行版
很多时候，不同发行版中会出现许多不同的错误-但是最好组织影响相似模块的错误（和功能），从而简化重复工作并最大程度地减少源自该工作的错误数量。始终提前做好发布路线图的准备；错误不断涌入-并且落入不同的目标发行版中，以最佳方式将一组不错的bug一起发布在一个良好的发行版中。将类似的错误组合在一起时，始终可以更好地了解相互矛盾的场景。

6.首先将任何新版本扩展到几个客户
在我们的案例中，我们看到首先在几个站点中对其进行测试，并且仅在有需求时才对所有其他站点应用该版本。很多时候，一些（或大多数）用户只会从稳定版本跳到另一个稳定版本。

7.回归测试
按照收集到的bug进行-建立回归套装。另外，如果可能，请标记严重的错误，并测试最重要的错误，这些错误将成为候选发布真正成为发布之前要测试的最低合格标准。

8.暂停和反思
当许多事情全速进行时，应该有时间休息一下-暂停一下，发布一些在功能上没有改善的东西。实际上有一段时间放假了。（持续时间与频率成反比）。例如，很多时候，我们拥有这些所谓的“清理”发行版，从功能的角度来看，这些发行版并没有什么新发现-但这有助于保持代码的可维护性。大多数此类发行版都是很好的后备点，您几乎永远不会回想起之前的历史。

9.也许最奇怪的是，
我常常很难实现这一目标，但肯定是个好办法。交换某些模块的所有者。当要求人们进行代码审查时，这种做法并没有带来多少好处。但是，当您必须认真对待该新代码时，当您交换作者时，潜在的“不良”疾患会在他们开始污染代码之前迅速被发现。当然，这会降低速度-但是，如果您经常这样做，人们很可能会掌握代码的各个部分并了解整个产品，这在其他方面也是很难教的。

10.最后但并非最不重要的一点是，
学会经常回到白板。您对这个功能将成为我们最初的设计的一部分的想法的思考越多，那时候我们会对设计有何看法？有时，增量工作的最大挑战就是我们太受我们首先构建的功能顺序的束缚，而且通常无法回到基础知识。诀窍是不断观察我们如何概括而不是适应此新功能或方案。这就要求设计必须保持最新，并且只有在我们经常回去做图纸时才会发生。此外，随着新一代程序员的加入，他们成为思想库的一部分，而不仅仅是放一些补丁。

编辑
11.跟踪变通方法和设计差距。
我们经常在时间表的压力下修复错误并在生产中发布。但是，当Bug处于设计级别时，需要进行很多更改，但是通常人们会通过一些捷径来解决这些错误，以便在截止日期之前完成。这样就可以了。但是，随着围绕解决方案的多种此类解决方案的增加，代码变得脆弱。专门跟踪已经存在多少设计差距。通常，当您与项目经理协商时间表时，最好让他/她承诺我们将以捷径交付，以节省生产，但我们也应时间表和资源以获得永久解决方案。

我也在一个小型开发团队中工作（仅我们两个），我们遇到了您提到的类似问题。对我们来说，主要的问题是我们俩都倾向于处理单独的任务，而对于我们来说，完成一项任务/功能，对其进行测试（仅由开发人员进行测试）并快速发布变得越来越普遍。这导致了许多小版本的发布，用户报告了应该在测试中容易发现的小错误。

为了改善我们的流程，我首先介绍了看板。该板的开始非常简单，只有几列（使用白板，索引卡和彩色磁铁进行设置）：

积压 要做| 完成

但是，这很快演变为反映了我们的实际过程：

积压 发展历程 开发人员 测试 UAT | 完成| 已发行

与董事会一起，我们有一个规则，即每个任务/功能都必须由另一位开发人员（以及实现该功能的开发人员）进行测试。因此，当卡片到达“完成”列时，它应该已经由至少2位开发人员进行了测试，并且还经过了用户接受度测试。

使用看板还有很多其他好处。对我们来说，它改善了沟通，并帮助我们共享了知识，因为我们俩都在某种程度上参与了每个任务。它也改善了我们的发布流程，因为我们现在可以确切地知道哪些任务/功能可以发布/完成，并且如果我们知道其他任务很快就会完成，有时可以推迟发布。对于团队以外的人员，董事会还可以作为快速参考，以了解我们已安排的任务，当前的工作进度以及最近发布的内容。

顺便说一句，我们使用彩色磁铁（每个开发人员一个）标记我们当前正在使用的卡，但另一种选择是添加泳道（行），每个开发人员一个并在相关的泳道中放置看板卡。同样，这有助于快速参考，以了解每个开发人员当前正在做什么。

我发现其他有用的链接：

看板应用于软件开发：从敏捷到精益

软件工程看板系统-视频

希望看板可以解决您问题中的第1点。关于代码审查，我们在开发人员测试阶段执行此操作，以便在审查后需要进行的所有更改在进入UAT之前都经过开发人员测试。回滚取决于您的环境，但是我们使用批处理文件将应用程序文件部署到终端服务器，该批处理文件重命名当前文件并从中央服务器跨新文件复制，并且可以通过将备份（先前文件）放在中央位置来相当容易地回滚并重新运行脚本。

您已经确定自己知道流程中存在影响软件质量的问题，尽管这个问题会引起一系列答案，但我的建议是着眼于软件工程主题并尝试学习什么主要的开发人员发现自己在该领域的工作越来越多。我建议您开始阅读一些有用的资源，以使自己入门。我想到了一些：

• Mary和Tom Poppendeick撰写的《精益软件开发》为有兴趣学习如何识别“废物”以及如何使流程变得更精简，更高效的人提供了不错的阅读材料。
• 丹·皮隆（Dan Pilone）和拉斯·迈尔斯（Russ Miles）共同撰写的Head First Software Development乍一看就像是那些“傻瓜书”中的一本，但是通过稍微混乱的呈现方式，它包含了与软件工程基础知识有关的大多数信息。并简要介绍了测试驱动开发。
• Dan North的页面介绍了BDD，它介绍了行为驱动开发，或者您可能更喜欢BDD Wiki。这些是BDD的入门参考，您可能需要研究工具和框架来为您提供帮助。要了解的重要一点是，BDD实际上是将TDD提升到更高的概念水平。它使您可以在考虑规范时考虑进行测试，并以编写规范时使用的相同语言进行测试。这些框架通常与其他单元测试框架集成在一起，因此，如果您确定测试不一定从BDD语法中受益，那么您将获得两全其美。
• Wikipedia的《敏捷软件开发文章》是有关敏捷软件开发的很好的入门书，并提供了一些有用的参考和一些开发社区中受人尊敬的人的文章链接。

为了改善您的工作方式，您需要让自己完全开放，并愿意跨出自己的舒适区，以便学会改进自己所做的事情而又不遵循某些可能会发现的概念。更加舒适。从个人经验上讲，这可能是最难做的事情，或者是在他人中鼓励的事情。

即使在您感到自己正在积极寻求改变的时候，变革也很难，所以，我真正能给您的最好建议是，研究多年来为使自己熟悉实践而开发的各种敏捷方法。认为最重要的方法（例如：单元测试，持续集成，重构等），然后选择看起来最接近您和您的团队最满意的方法。做出决定后，请调整实践和开发过程，以使其适合您的团队希望工作的方式，同时牢记那些精益的校长以及您希望如何工作，以便您的团队可以在此过程中产生最大的价值。浪费最少。最后，

如果您认为您的流程仅需要调整，但是您担心自己的工具链不能完全满足您的需求，那么可以考虑在那里进行改进。至少应优先考虑使用持续集成集成产品（例如Continuum，Cruise Control或Hudson）和问题跟踪系统（例如Jira或Redmine）来帮助您自动化某些构建和发布流程，并检查您的错误和功能请求。

现实情况是，无论您的RAD流程如何，如果您不花时间投入使团队“正确”解决问题，您的问题只会随着时间的流逝而继续增长，并且您对可用时间的感知会不断增加。相应地缩小。在沉重的时间压力下，大的变化通常是不可能的，但是请尝试给自己一点“摆动空间”，以便将系统放置到位，以帮助您朝着团队的理想方法愿景迈出第一步。

每当我听到有关缺陷的信息时，我的第一个问题就是有关缺陷的来源以及在何处发现和消除缺陷的信息。缺陷去除效率是衡量和跟踪缺陷的一种好方法。通过了解缺陷起源于何处并努力改善这些阶段的流程，可以减少项目的时间和成本。众所周知，将缺陷修复到更接近注入点的位置更便宜，因此一旦知道了缺陷的来源，就可以查看活动更改以改善这些阶段。

获得有关缺陷来源的信息后，您可以准确查看要应用的技术。审查需求，设计和代码，自动测试，静态分析，持续集成以及更广泛的用户驱动测试可能是您应该考虑的选项，具体取决于哪个阶段会产生缺陷。

为了扩展对代码审查的需求，您还应该根据模块的优先级和风险来考虑不同级别的代码审查。低风险，低优先级的模块可能根本不需要代码审查，或者可能只是简单的桌面检查，而其他开发人员只需自己阅读代码并提供注释，即可使用。其他代码审查技术包括结对编程，演练，批判和与不同数量的开发人员进行检查。

为了回滚，我希望使用某种脚本使该过程自动化，以使其更快，更不易出错。在一个理想的世界中，我希望提高出厂产品的质量，从而不必回退，您可以实现这一目标。虽然具备此功能可能是个好主意，但要使其尽可能轻松。

正如其他人指出的那样，添加回归测试将有助于避免将来出现相同的缺陷。但是，如果遇到新的缺陷，那么可能是时候在代码中添加断言（又称合同），以指定类和方法的前置条件，后置条件和不变量。

例如，如果您的类中某个方法只能接受10到25之间的数字（这称为前提条件），则可以在该方法的开头添加一个assert语句。当该断言失败时，该程序将立即崩溃，您将能够遵循导致该失败的方法链。

Python，PHP和其他编程语言是动态类型的，不会在方法中添加很多条件。要使某项工作正常运行，所需要做的就是实现一个特定的方法。我怀疑您的方法需要更多条件。您需要定义和测试以确保方法可以在其环境中实际运行。

对于C / C ++程序，我发现在测试内存分配中添加断言对于减少程序中的内存泄漏数量非常有帮助。