编译,为什么？
示例(您不必回复示例,但请说明您的目录设置)：
<Layout MyPersonalizedLayout>
prefix: /usr
exec_prefix: ${prefix}
bindir: ${prefix}/bin
sbindir: ${prefix}/sbin
libdir: ${prefix}/lib/application_name
libexecdir: ${prefix}/lib/application_name/modules
installbuilddir: ${prefix}/lib/application_name/build
mandir: ${prefix}/man
sysconfdir: /etc/application_name
includedir: ${prefix}/include/application_name
localstatedir: /var
runtimedir: ${localstatedir}/run/application_name
logfiledir: ${localstatedir}/log/application_name
</Layout>
>您考虑了哪些步骤以及哪些步骤
你在重新编译之前搞乱了
或升级申请？
>你如何跟踪所有的
配置您上次习惯的选项
编译一个申请？
>您是否定期备份
从配置文件？多常 ？
>你有特殊/不同的
升级系统,以便您可以维护
最后的工作申请,直到
新的准备推出？
>你通常测试一个编译
在对你进行实践之前
生产服务器,你是什么
这样做之前的考虑因素
我不是很喜欢使用yum,apt-get和其他类似安装管理器的人,而我相信他们对某些东西很好我更喜欢拥有自己的控制和我需要管理的应用程序中的可能性所以我会想知道每个人如何威胁这个.
如果这个问题得到了3个以上的答案,我会把它变成一个社区维基,直到那时我才会要求你把它变成一个
解决方法
我仍然使用系统包和本机系统构建实用程序.使用RHEL,Kickstart对于初始构建来说绝对必不可少.对于常见的用户态实用程序,我倾向于默认为包.我只从源代码编译主服务器角色.例如：数据库,Web服务器,代理服务器,负载平衡器等.
A1：我希望尽可能遵循Filesystem Hierarchy Standard.
A2：这是一个复杂的话题.如果升级需要升级库,则其他软件也可能需要这些库.构建角色的所有核心要求我倾向于按源编译.库我经常在构建之间共享并重新编译针对它们编译的任何软件,因为我很少静态编译.如果您的更改经过测试并正确分阶段进行生产,则可以将风险降至最低.
A3：配置选项通常在构建中在所有服务器上应用时指定.在唯一配置的情况下,例如Web服务器集群上的特定VirtualHost,我将在Revision Control System中维护这些配置文件.在以编程方式构建服务器之后,将完成系统核对表以进行完整性检查并配置任何选项最好手动处理.您也可以使用配置管理系统来提供帮助,但是根据您的构建标准化的程度,它可能会过时.
A4：是的.每晚备份所有唯一的配置文件.
A5：升级系统主要是内置于初始脚本中的逻辑,其周围有一个包装脚本.这允许升级作为构建的一部分进行维护.有时,在bash和pipe中使用for循环的更简单的脚本集通过ssh进行更改.我们的想法是让所有变更都得到适当的标准化.
A6：在升级到生产之前,所有更改都在测试环境中进行测试和验证.应验证所有预期的功能是否可操作.
老实说,我可以根据你的问题写一本关于这个主题的书.您实际上是在询问如何正确地构建,标准化和维护生产环境.我的答案并非详尽无遗,并且有适用于所有方法的基本标准.您可能会受益于Practice of Systems and Network Administration一书中建立的基础.
我还就这个问题写了其他答案.也可以看看：
Managing an application across multiple servers,or PXE vs cfEngine/Chef/Puppet
