我是一名Unix sysadmin转行的程序员,因为这是我目前最关心的事情,所以我想听听一些关于编写软件以便易于部署、升级和长期维护的最佳实践和最坏实践。我不是在谈论代码本身的长期维护;相反,您使用什么准则来防止您的软件变成无法安装的混乱?
我现在最恼火的就是硬编码配置。我正在与我们的开发团队合作,在我的全职工作中简化我们应用程序的部署,这样我就可以完全自动化部署过程的每一步。这些应用程序的大部分配置实际上是硬编码的,无论是在构建时还是在代码库中,这使得在服务器上实际设置软件的过程非常非常痛苦。
幸运的是,我全职工作的团队很有才华,和我一样希望看到这个问题得到解决,所以事情进展顺利。
至于“最佳实践”,从Unix的角度来看,我真的很喜欢软件是或可以是自包含的。因此,我应该能够将应用程序安装到一个目录中,然后能够在不导致应用程序完全混乱的情况下移动该目录。这真的只需要一点启动路径检测,它让我作为系统管理员的生活变得更美好。
有哪些方法可以简化服务器类型应用程序的部署过程(在Windows和Unix上),同样,在将代码推出时,您遇到的一些事情会变成真正的噩梦吗?
发布于 2009-04-04 01:19:39
1-管理你的外部开发-如果你假设一个文件必须在x上,那么让x成为可配置的。或者使用相对路径作为一个例子。
2-不要硬编码配置。
3-避免二进制依赖(Windows的COM和DLL地狱日)
4-让它自动化,或者让它变得如此简单,以至于大脑死亡的猴子可以在睡眠中做到这一点。例如,现在我所要做的就是解压缩一个文件,然后部署我的web应用程序,我有一个需要运行的sql脚本,并且处理了数据库。它不应该花费更多的clicks...and,绝对不需要做任何配置更改,这一切都应该是脚本化的。
发布于 2009-04-04 01:40:07
沿着Filesystem Hierarchy Standard行驶。让应用程序完全自包含(二进制文件、配置、头文件、库都在一个目录中)打破了这一标准,这使得处理许多事情变得更加痛苦。
./configure、make、make install (如果你需要一个不同的构建系统,或者一个合适的变种)应该是安装你的程序的步骤。configure应该找到任何依赖项,启用或禁用任何可选功能,并允许设置--prefix (以及exec-prefix、bindir等)为各种组件选择适当的安装位置。有关更多信息,请参阅GNU Coding Standards (我不同意所有的GNU编码标准,但是关于configure应该如何工作的建议很好)。
包括描述您的程序采用的所有命令行选项的man页面。您可以在其他地方获得更好的文档(info、超文本标记语言等),但我应该能够使用man作为命令行选项的快速参考。不要像GNU那样,只在一些man页面中放置存根,并指向info文档以获取更多信息。
发布于 2009-04-04 01:43:55
软件设计和环境的稳定性在很大程度上决定了软件的可部署性。每个应用程序都应该是可配置的,并让应用程序养成一个启动脚本来验证其环境并生成有意义的错误消息的习惯。控制对服务器的访问,并坚持要求修改这些服务器的团队已经在稳定的测试环境中进行了适当的测试。成为测试环境的拥护者。应用程序团队所做的更改应尽可能编写脚本,包括实施计划、验证计划、取消计划和取消验证计划。提供一个自动清理临时文件和工件的位置。/u/spool/01每天都会被清理。/u/spool05每五天清理一次。/u/spool30每30天清理一次。如果多个应用程序共享同一服务器,请考虑静态链接共享代码。避免链接的鼠巢。避免共享挂载。支持日志记录标准。将测试系统与生产系统隔离。创建不在当前目录或一组固定目录之外写入的标准。在所部署的二进制文件和它所来自的源代码管理系统之间创建清晰的链接。监控您的服务器是否有失控的进程、充满的磁盘和网络连接。对于权限位要严苛。找出奖励系统正常运行时间的方法。
https://stackoverflow.com/questions/716248
复制相似问题