4

有没有人有将成品传递给安装团队的经验？

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

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

具体来说：

  • 您使用了哪些工具来改善团队之间的沟通/协作？
  • 您使用了哪些技术解决方案？
  • 您使用了哪些政策？
  • 有没有人在编写安装后验证工具方面取得任何成功？

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

4

5 回答 5

3

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

  1. 运动部件少

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

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

  1. 部署指南

这都是大写的，因为它胜过第一步。我说的是一个非常彻底的指南。

不应该说

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

应该说

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

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

2.1回滚计划

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

2.2测试部署指南

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

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

于 2009-05-27T19:57:36.907 回答
1

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

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

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

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

于 2009-05-27T19:36:12.533 回答
1

是的。一些基本规则：

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

  • 没有“安装团队”。开发人员应该负责开发一个工作系统，而不是他们扔在墙上的一堆碎片，让其他一些可怜的 sap 开始工作。

  • 拥有完全自动化的部署/升级过程。部署不应该需要手动决策，因为总有一天有人会不小心做出错误的决定。

  • 如果部署失败，请修复自动化并重新发布。不要将系统就地投入生产，因为人们总有一天会忘记将修复检查回源代码存储库。

  • 在开发过程中定期测试部署/升级过程。最好在每次提交时，作为持续集成过程的一部分。

  • 确保测试环境尽可能接近生产环境。理想情况下，唯一的区别应该是密码。

  • 作为部署的一部分运行环境测试。我通常在系统本身中实现这些，以便它自我测试并报告其运行时环境的问题。

  • 轻松回滚失败的部署。

于 2009-05-27T20:34:56.423 回答
0

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

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

于 2009-06-02T13:59:00.580 回答