如何编写可部署的软件？

Question

我是一个Unix系统管理员变身的程序员，因为我现在很接近并且亲爱的，所以想要在编写软件时听到一些最佳和最差的实践，这样就很容易长期部署，升级和维护。我不是在谈论代码本身的长期维护;相反，您使用什么准则来防止软件变成无法安装的混乱？

我目前的烦恼是硬编码配置。我正在与我们的开发团队一起完成我的全职工作，以简化应用程序的部署，这样我就可以完全自动化部署过程的每一步。这些应用程序的大部分配置实际上是在构建时或代码库中进行硬编码，这使得在服务器上实际设置软件的过程非常非常痛苦。

幸运的是，我全职演出的团队很有才华，希望能像我一样修复这个问题，所以事情进展顺利。

至于“最佳实践”，从Unix的角度来看，当软件是或者可以是自包含的时候，我真的很喜欢它。所以，我应该能够将一个应用程序安装到一个目录中，然后能够移动该目录，而不会导致应用程序完全失控。这并不仅仅需要一点启动路径检测，它使我作为系统管理员的生活变得更加美好。

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

Answer 1

1 - 管理您的外部指标 - 如果您假设某个文件必须位于x，则x可配置。或者使用相对路径作为一个例子。

2 - 不要硬编码配置。

3 - 避免二进制依赖（来自Windows的COM＆amp; DLL Hell Days）

4 - 自动化它或使它如此简单，脑死亡的猴子可以在睡眠中做到这一点。例如，现在我所要做的就是解压缩文件并部署我的Web应用程序，我有一个需要运行的sql脚本并且处理了数据库。它不应该只需要点击几下......并且如果所有脚本都不需要，则不需要进行任何配置更改。

Answer 2

关注Filesystem Hierarchy Standard。让应用程序完全自包含（二进制文件，配置文件，头文件，libs都在一个目录中）打破了这个标准，这使得处理许多事情变得更加痛苦。

./configure，make，make install（或者如果您需要不同的构建系统，则为适当的变体）应该是安装程序的步骤。 configure应该找到任何依赖项，启用或禁用任何可选功能，并允许设置--prefix（以及exec-prefix，bindir等）为各种组件选择适当的安装位置。有关更多信息，请参阅GNU Coding Standards（我不同意所有GNU编码标准，但有关configure应该如何工作的建议很好。）

包含描述您的程序所采用的所有命令行选项的man页面。您可以在其他地方（info，HTML，等等）获得更好的文档，但我应该能够使用man作为命令行选项的快速参考。不要像GNU那样只在一些man页面中放置存根，并指向info文档以获取更多信息。

Answer 3

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

Answer 4

我建议您将部署和维护都视为需要测试的方案，其方式与测试软件操作方面的方式完全相同。

当发现错误时，应该创建一个回归测试，也许还要进行单元测试。以完全相同的方式，当客户在部署或维护软件时遇到问题，并且如果它更像是软件问题而不是文档或培训问题，那么应该在测试计划中添加测试以确保问题不会再发生。

当然，只要这些测试可以自动化，它们应该至少在每晚构建之后运行;在每个持续集成构建中充其量。至少，应该在将应用程序部署到将要测试的QA计算机上时运行产品的安装脚本或安装程序。

Answer 5

忏悔：我点了这个问题，上面写着“怎么写可悲的软件？”但现在我在这里，我应该开枪......

我想知道从敏捷书中拿一片叶子可能有帮助吗？在短期迭代（比如说一到四周）中工作，并确保在每次迭代结束时进行不少于部署。这样，你就可以很好地部署你的应用程序 - 如果需要太长时间，你将无法完成任何其他工作。部署的应用程序在遇到问题时会从用户社区反馈出来，并且可以优先处理后续迭代中的操作。