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

有没有人有向安装团队提供成品的经验

我们的产品可以通过RPM安装，但也需要复制一些MySQL数据、修改一些配置文件和运行一些开发脚本。有一个安装团队是很好的，但开发是随时待命的，每次安装后，我们都会在需要支持的几个小时后接到客户的电话

我们确实从每一次事件中吸取了教训，但更积极一点对我们的客户、我们的声誉和我的睡眠都有好处

具体而言：

• 您使用了哪些工具来改进 双方的沟通/合作 球队
• 您使用了哪些技术解决方案
• 你采用了什么政策
• 有人在编写安装后验证工具方面取得过成功吗

编辑：

---

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

没有针对您的特定问题，但曾经有一个开发人员和测试人员团队将web应用程序部署到一组服务器上进行测试和验证

在发布时，客户获得了可部署文件，并按照规范进行了部署。。。对于一组服务器，与我们的开发服务器完全不同

大量bug涌入，混乱接踵而至，客户怒不可遏，可怜的开发人员无法入睡

我的建议是最明显的；确保开发环境与生产环境匹配，以避免特定于环境的错误。

是。 一些基本规则：

交付产品时务必签名并盖章。使用zip（或任何有校验和的东西），不要传递单独的文件或目录

将其刻录在CD上，并实际移交。这样你就知道你有一份有效的硬拷贝（和备份）。你会惊讶地发现，由于CD刻录机会无声地损坏文件，所以很容易搞砸安装

安装团队（或QA）应该收到客户收到的东西，而不是更少。假设他们对你产品的了解比最愚蠢的顾客少

当然，您应该始终按版本对所有此类交付进行编目

打印版本附带的任何安装/部署/用户指南，并实际移交。像纸一样。即使文档自上一版本以来没有更改。我浪费了很多时间帮助QA调试安装，后来意识到他们使用了错误的安装指南

---

这基本上是阿萨夫的答案，重点不同。 在部署的双方都进行了部署之后，有两个主要项目可以确保良好的部署

---

运动部件少

这意味着，如果您可以选择提供一些文件并让部署人员将它们放在生产环境的特定文件夹中，或者您可以将这些文件预先放置在文件夹结构中，让部署人员将其复制到根目录中。更简单的是，一个批处理文件。或者MSI。如果他们必须运行SQL脚本，那么请清楚地显示它们的位置

基本上，这一步归结为允许开发人员创建脚本和批处理文件，并尽可能地实现自动化（heh）。这样，部署人员（他对应用程序的了解程度不如你）就不会介意阅读他们应该如何处理剩下的三个文件。（嗯，你应该把它们放在文件夹A、B、D和ZZ中）

---

部署指南

这都是因为它胜过了第一步。我说的是一个非常全面的指南

不应该说

“将地图相关文件移动到地图应用程序数据文件夹中。”

应该说

“*将文件x、y、z（位于部署包的文件夹x中）移动到地图应用程序数据文件夹（位于D:\AppName\Map App Data）*.”

甚至可以说“远程进入X服务器，然后执行y”，因为您可能认为部署人员应该在哪台服务器上是很清楚的，但是对于多服务器设置，在哪里应该执行哪些操作会变得非常棘手。对于一个文档来说，这种彻底的方式意味着任何人都可以部署，即使是你没有机会培训过的人

---

2.1回滚计划

将回滚计划直接放入部署指南中。如果部署出错，并且偶尔会出错，在部署人员能够唤醒知道发生了什么的人之前，您不希望让服务器离线。它应该就在他们面前。即使这对你来说是显而易见的，也要记住，你刚刚花了四个星期全神贯注于这个项目，而这个人花了最后20分钟。他们根本无法被解释为知道你没有告诉他们什么

---

2.2测试部署指南

自己完成这些步骤。或者更好的办法是，让一个不在项目中的同事和你的指导一起尝试部署到UAT，你坐在他们旁边。只要他们弄错了，就换指南。在部署出现错误的任何地方（您以前见过的情况），在指南中添加一个脚注，解释出现这种情况的原因，以及如何在可能的情况下修复它。至关重要的是，您的部署指南中没有错误，因为当您编写部署指南时，您实际上是在对部署进行操作（因为您知道如何操作），并且您还可以在其中熟睡。但是，这也意味着任何错误都在你身上

请为我遗漏的任何内容添加评论，我会把它扔掉。

• 没有“指令”