如何编写可部署软件?

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

3-避免二进制依赖关系(来自Windows的COM&DLL)

4-自动化或使之如此简单一个脑死亡猴子可以在他们的睡眠。例如,现在我所要做的就是解压一个文件,然后部署我的web应用程序,我有一个sql脚本需要运行,DB被处理。它不应该超过几次点击…没有绝对没有配置的变化应该需要做这一切都应该是脚本。

跟随 Filesystem Hierarchy Standard . 让应用程序完全独立(二进制文件、配置文件、头文件、libs都在一个目录中)打破了这一标准,这使得处理许多事情更加痛苦。

./configure , make , make install 安装程序的步骤应该是(如果需要不同的构建系统,也可以是适当的变体)。 configure --prefix (和 exec-prefix , bindir 等)为各种组件选择适当的安装位置。看到了吗 GNU Coding Standards 更多信息(我不同意所有的GNU编码标准,但建议如何 配置 应该工作是好的)。

包括 man info ,HTML,随便什么),但我应该可以使用 作为命令行选项的快速参考。别这样 GNU 把树桩放在一些 信息 有关详细信息,请参阅文档。

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

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

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

可悲的