企业级DevOps实践01-版本控制之将所有内容纳入版本控制系统

企业级DevOps实践01-版本控制之将所有内容纳入版本控制系统

制品管理可能是管道最重要的特征。在最基本的层面上，管道从源代码创建二进制/包制品，并将它们部署到适当的基础设施，为正在部署的应用程序提供动力。

关于资产和源代码要遵循的最重要的规则如下：

构成应用程序的所有文件都应使用源代码控制进行管理。

不幸的是，尽管这条规则看起来很基本，但仍有很多组织未能遵守它。传统上，开发人员仅将版本控制系统用于应用程序的源代码，而忽略了其他支持文件，例如安装脚本、配置文件或测试数据。

参与应用程序生命周期的所有内容都应检查到源代码控制中。这包括但不限于：

源代码 构建脚本

管道定义文件 配置文件

测试和测试数据 数据库模式

数据库更新脚本 基础设施定义脚本

清理/安装/清除脚本 其他相关文件

最终目标是任何人都可以检查与应用程序相关的所有内容，并可以在本地或任何其他替代环境中重新创建它。

我们看到的一个常见反模式是使用特殊脚本进行部署，该脚本仅在特定机器或特定团队成员的工作站上可用，甚至是 wiki 页面中的附件，等等。

版本控制还意味着所有这些资源都经过审核并拥有所有更改的详细历史记录。如果您想查看应用程序在 6 个月前的样子，您可以轻松地使用版本控制系统的工具来获取该信息。

请注意，即使所有这些资源都应该进行版本控制，但它们不必位于同一个存储库中。无论您使用多个存储库还是单个存储库，这是一个需要仔细考虑的决定，并且没有明确的答案。然而，重要的部分是确保一切确实是版本控制的。

尽管 GitOps 是使用 Git 操作进行推广和部署的新兴实践，但您不应该仅因为使用GitOps 而来遵循此最佳实践。无论您遵循何种实际软件范例，拥有项目资产的历史和审计信息始终是一件好事。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。