Deployment 如何编写可部署软件？

我是一名Unix系统管理员出身的程序员，因为这是我目前最关心的问题，所以我想听听关于编写软件的一些最佳和最差做法，以便易于部署、升级和长期维护。我不是说代码本身的长期维护；相反，您使用什么准则来防止您的软件变成无法安装的混乱

我现在最讨厌的是硬编码配置。在我的全职工作中，我正在与我们的开发团队合作，以简化应用程序的部署，这样我就可以完全自动化部署过程的每个步骤。这些应用程序的大部分配置实际上都是硬编码的，无论是在构建时还是在代码库中，这使得在服务器上实际设置软件的过程非常非常痛苦

幸运的是，我全职工作的团队很有天赋，他们和我一样希望看到这个问题得到解决，所以事情进展顺利

至于“最佳实践”，从Unix的角度来看，我非常喜欢软件是或可以是自包含的。因此，我应该能够将应用程序安装到一个目录中，然后能够在不导致应用程序完全失控的情况下移动该目录。这实际上只需要一点启动路径检测，它让我作为系统管理员的生活变得更加美好

---

有哪些方法可以简化服务器型应用程序（在Windows和Unix上）的部署过程？同样，当需要将代码推出时，您遇到了哪些事情会变成一场真正的噩梦？

1-管理您的外部依赖性-如果您假定文件必须位于x，使x可配置。或者以相对路径为例

2-不要硬编码配置

3-避免二进制依赖关系（Windows中的COM和DLL地狱日）

4-实现自动化或使之变得如此简单，一只脑死亡的猴子可以在睡眠中完成。例如，现在我所要做的就是解压一个文件，部署我的web应用程序，我有一个sql脚本需要运行，DB得到处理。它不应该需要更多的点击次数……而且不需要绝对的更改，也不需要进行配置更改。这些都应该是脚本化的。

按照下面的说明进行操作。让应用程序完全独立（二进制文件、配置文件、头文件、libs都在一个目录中）打破了这一标准，这使得处理许多事情更加痛苦

/configure

，

make

，

make install

（如果需要不同的生成系统，也可以使用适当的变体）应该是安装程序的步骤

configure

应查找任何依赖项，启用或禁用任何可选功能，并允许设置

--prefix

（和

exec prefix

，

bindir

等）为各种组件选择适当的安装位置。有关更多信息，请参阅（我不同意所有的GNU编码标准，但是关于

配置

应该如何工作的建议很好）

---

包括

man

页面，描述程序采用的所有命令行选项。您可以在其他地方获得更好的文档（

info

、HTML等等），但我应该能够使用

man

作为命令行选项的快速参考。不要像

GNU

那样，只在一些

man

页面中添加存根，并指向

info

文档以获取更多信息。

软件设计和环境的稳定性都对软件的可部署性做出了重大贡献。每个应用程序都应该是可配置的，并使应用程序习惯于使用启动脚本来验证其环境并生成有意义的错误消息。控制对服务器的访问，并坚持修改这些服务器的团队已经在稳定的测试环境中进行了适当的测试。成为测试环境的拥护者。应用程序团队所做的更改应尽可能编写脚本，包括实施计划、验证计划、回退计划和回退验证计划。提供一个自动清理临时文件和工件的地方/u/spool/01每天都要清洗/u/05每五天清洁一次/u/30每30天清洗一次。如果多个应用程序共享同一服务器，则可以考虑静态链接共享代码。避免老鼠筑巢的链接。避免共享挂载。拥护伐木标准。将测试系统与生产系统隔离。创建不在当前目录或固定目录集之外写入的标准。在所部署的二进制文件和源代码管理系统之间创建一个清晰的链接。监视服务器是否有失控的进程、磁盘填充和网络连接。对许可位要严苛。找出奖励系统正常运行时间的方法

我建议您将部署和维护视为需要测试的场景，方法与测试软件的操作方面完全相同

当发现一个bug时，应该创建一个回归测试，也许还有单元测试。以完全相同的方式，当客户在软件的部署或维护方面遇到问题时，如果问题更多的是软件问题而不是文档或培训问题，则应在测试计划中添加测试，以确保问题不会再次发生

---

当然，在这些测试可以自动化的程度上，它们至少应该在每晚构建之后运行；在每一个持续集成构建中，最好的情况是。至少，产品的安装脚本或安装程序应该在将应用程序部署到将要测试的QA机器上时运行。

坦白：我点击了这个问题，上面写着“如何编写糟糕的软件？”但现在我在这里，我应该试一试