如何避免将成品传递给安装团队的陷阱？答案

【问题标题】：How can I avoid pitfalls passing the finished product to the install team?如何避免将成品传递给安装团队的陷阱？
【发布时间】：2009-05-27 19:25:48
【问题描述】：

任何人都有将成品传递给安装团队的经验吗？

我们的产品可以通过 RPM 安装，但也需要复制一些 MySQL 数据、修改一些配置文件并运行一些开发编写的脚本。拥有一个安装团队固然很好，但它是随叫随到的开发，每次安装后，我们都会在下班后接到客户的电话，我们必须提供支持。

我们确实从每个事件中吸取了教训，但如果更加积极主动，对我们的客户、我们的声誉和我的睡眠都有好处。

具体来说：

您使用了哪些工具来改进之间的沟通/协作团队？
您使用了哪些技术解决方案？
您使用了哪些策略？
有没有人成功编写过安装后验证工具？

编辑： 我应该澄清一下，我不是在谈论开发和/或 QA 应该发现的软件故障。问题是客户打电话说“选项 A 突然不可用”，因为它没有配置为打开，或者“我无法登录”，因为身份验证服务器配置不正确。

【问题讨论】：

facepalm facepalm facepalm
@Robert：让 Malfist 休息一下。他听说虚拟机很好，现在他打算把它推广到每个他可以尝试的地方，让自己看起来很聪明。
主观和论证？？投了这种票的人——请在你不在时锁定你的电脑，你的猫显然在你的桌子上并点击链接。
@Rich B，虚拟机非常适合在隔离环境中进行测试。但是，我没有很好地阅读这个问题，并认为 OP 正在做测试。当我意识到我错了，我删除了评论。
/me 拍了拍 Malfist 的头。

标签： deployment communication

【解决方案1】：

这基本上是阿萨夫的答案，重点不同。参与过部署的双方，有两个主要项目可以确保良好的部署。

活动部件很少

这意味着，如果您可以选择提供一些文件并让部署者将它们放在生产环境中的某些文件夹中，或者您可以将文件预先放置在文件夹结构中，然后让部署者复制它入根。或者更简单，一个批处理文件。或微星。如果他们必须运行 SQL 脚本，那么清楚地显示他们在哪里。

基本上，这一步归结为允许开发人员创建脚本和批处理文件，并尽可能人工（呵呵）自动化。这样一来，部署人员（他们并不像您一样了解应用程序）就不会想到他们应该对剩下的三个文件做什么。（呃，你应该把它们放在文件夹 A、B、D 和 ZZ 中）

部署指南

这一切都在大写，因为它胜过第一步。我说的是一个非常详尽的指南。

不应该说

"将地图相关文件移动到 Map-App-Data 文件夹中。"

应该说

"*将 文件 x,y,z（位于部署包的 文件夹 X 中）移动到 Map-App-Data 文件夹（位于 D :\AppName\Map-App-Data)*"。

执行甚至说“远程进入 X 服务器，然后执行 y”的动作，因为您可能认为部署者应该在哪个服务器上很清楚，但对于多服务器设置，它可能会变得非常棘手应该在哪里做。给定一份如此详尽的文档意味着任何人都可以部署，即使是您没有机会就正在发生的事情进行培训的人。

2.1 回滚计划

将回滚计划直接放入部署指南中。如果部署出错，而且它们偶尔会出错，那么您不希望服务器离线，直到部署人员能够唤醒知道发生了什么的人。它应该就在他们面前。即使这对您来说似乎很明显和简单，但请记住，您在过去的四个星期里全神贯注于这个项目，而这个人已经花了最后 20 分钟。他们根本不可能知道你没有告诉他们的事情。

2.2 测试部署指南

自己完成这些步骤。或者更好的是，请一位不在项目中的同事与您的向导一起尝试部署到 UAT，然后您坐在他们旁边。任何地方他们弄错了，改变指南。部署出错的任何地方（您以前见过的情况）在指南中添加一个脚注，解释为什么会出现这种情况，以及如果可能的话如何解决它。至关重要的是，您的部署指南没有错误，因为当您编写部署指南时，您实际上是在执行部署（因为您知道如何操作）并且您获得了通过它睡觉的好处。但是，这也意味着任何错误都在你身上。

请为我错过的任何内容添加 cmets，我将把它扔进去。

【讨论】：

【解决方案2】：

不是针对您的特定问题，而是曾经有一个开发人员和测试人员团队将 Web 应用程序部署到一组服务器以进行测试和验证。

到了发布时间，客户得到了可部署的文件，并按照规范将其部署到了一组与我们的开发服务器完全不同的服务器上。

大量的错误涌入，混乱接踵而至，客户大发雷霆，可怜的开发人员无法入睡。

我的提示是最明显的提示之一；确保开发环境与生产环境匹配，以避免环境特定的错误。

【讨论】：

所以你建议不要让你的程序灵活，而是让它绑定到特定的设置？
听起来不错...然后您将您的程序发布为一个可以在主机环境中以无缝模式运行的自执行虚拟机映像，并且它可以像机器一样运行开发机器:)
在您可以将您的项目出售给多个客户的项目中，没有。那将是在踢自己的脚。在客户订购的项目中，由客户支付费用并将部署在客户服务器上。是的，我建议任何人让程序在客户特定设置上完美运行，高于一切。如果您说“它可能不适用于您的环境，但在我们的环境中非常棒”，客户将不会更高兴。
@varl，您刚刚说明了为什么应该使其灵活，以便它可以在您的系统和您的客户系统上运行。 @workmad3，哈哈。那会是一团糟。
@Malfist 谁会为您花费的时间支付费用以确保它适用于不同的设置？谁来为验证和解决不同设置问题所花费的时间买单？谁将为验证和清除不同设置上的错误所需的测试人员付费？客户？不，客户不会愿意为开发人员知道自己拥有灵活的代码而获得的自我提升付费。尤其是现在。

【解决方案3】：

是的。一些基本规则：

始终交付签名并盖章的产品。使用 zip（或任何具有校验和的东西），不要传递单个文件或目录。
将其刻录在 CD 上，然后将其实际移交。这样你就会知道你有一个有效的硬拷贝（和一个备份）。您会惊讶地发现，由于 CD 刻录机会静默地损坏文件，因此搞砸安装是多么容易。
安装团队（或 QA）应该收到客户收到的准确信息，不能少。假设他们比最愚蠢的客户更了解您的产品。
当然，您应该始终保留按版本分类的所有此类交付的存储库。
打印该版本随附的任何安装/部署/用户指南，并实际交付。作为纸。即使该文档自上一个版本以来没有更改。我浪费了很多时间来帮助 QA 调试安装，后来才意识到他们使用了错误的安装指南。

【讨论】：

【解决方案4】：

没有“安装团队”。开发人员应该负责开发一个可以工作的系统，而不是他们扔在墙上的一堆碎片，让其他一些可怜的 sap 开始工作。
拥有完全自动化的部署/升级过程。部署应该不需要手动决策，因为总有一天有人会不小心做出错误的决定。
如果部署失败，请修复自动化并重新发布。不要将系统就地投入生产，因为人们总有一天会忘记将修复检查回源代码存储库。
在开发过程中定期测试部署/升级过程。最好在每次提交时作为持续集成过程的一部分。
确保测试环境尽可能接近生产环境。理想情况下，唯一的区别应该是密码。
在部署过程中运行环境测试。我通常在系统本身中实现这些，以便它自我测试并报告其运行时环境的问题。
轻松回滚失败的部署。

【讨论】：

@Nat - 感谢您的回复，但是，1）消除安装团队会减少一个故障点，但这需要开发人员成为安装操作系统和网络配置方面的专家，并且需要时间远离实际发展。 2）我们几乎不会把一堆碎片扔到墙上，我们有一个经过全面测试和质量保证的 RPM 可安装应用程序，需要一些手动配置。每个客户都是不同的，所以我们需要找到一种方法来确保配置正确。
注意，我没有说你应该摆脱这些人。我说你应该摆脱一个单独的团队。两个团队是沟通和学习的瓶颈。有些程序员编写代码但没有参与使其可顺利部署，因此没有尽可能快地学习他们必须部署到的所有平台和环境。您有一个安装团队，他们无法更改软件以使其更易于使用。您需要打破程序员和“安装人员”之间的障碍，以便人们可以更有效地合作。

【解决方案5】：

经过一番讨论，我们的构建团队提出了使用 Jump Start 的想法。我们可以打包我们的 RPM 和任何必要的配置（MySQL 命令、对 httpd.conf 的更改等...）。一旦我们遇到安装问题，我们可以修改脚本；这几乎可以保证同样的错误不会再犯。

一旦我们真正开始使用这个直播，我会更新。

【讨论】：