是否存在与禁用功能的生产代码相关的风险?

时间:2012-07-25 01:43:52

标签: deployment workflow release

我并不是要模糊,但我对发布故意关闭的代码的想法持怀疑态度,而且我无法找到任何与该主题相关的好消息来源。这可能真的是一个“依赖”的问题,在这种情况下,请随意投票并删除。

我的具体情况是我们自己托管的网络应用程序,每两周一次的“发布”(推向生产)。此外,我们目前使用的是Subversion,尽管在不久的将来会转向Git。

我听说过的一个场景是部署一个依赖于具有尚未发布的已知功能的库的功能,无论是您自己的库还是第三方。

另一个是在功能完成时释放部分功能,但在生产中所有部分组合在一起时禁用。

虽然这两个起初听起来都不错,但我质疑生活中禁用的代码的价值,特别是作为一般做法。看起来这可能导致未完成的功能混乱代码库,并导致比所需更大的配置文件,只是为了提供禁用/启用功能的方法。

如果有的话,部署故意禁用代码的好处是什么,以及在我们以任何频率执行此操作之前需要解决哪些问题?

此外,请分享任何链接,并告诉我这种做法是否有名称。

2 个答案:

答案 0 :(得分:1)

它被称为feature toggles

我认为使用基于角色的授权启用/禁用功能并不存在风险。您对代码混乱和增加配置的担忧是有效的,但持续交付的拥护者会争辩说替代方案(功能分支)更糟糕。

答案 1 :(得分:0)

我见过这样做的主要依据是将代码推送与配置推送分开。如果您可以将它们分开,则更容易确定您是否有错误的版本或错误的配置。默认情况下,您可以关闭不完整功能X的版本,继续推送可以回滚的版本而不启用它,然后当您决定打开它时,您可以更新您的配置,如果需要也可以回滚。 / p>