什么是源代码管理和配置管理最佳实践?

时间:2009-04-14 21:17:59

标签: version-control configuration-management

我正在考虑一个列表,我可以将其他开发人员引用到:

  1. 一个构建脚本,例如 makefile , 将构建并测试整个项目
  2. 需要构建的所有组件 系统需要源控制
  3. 有人有这样的名单吗?按优先顺序?


    更新 - 添加了一些fyi细节

    有问题的系统包括C ++和makefile,带有ant的导致WAR的Java,以及powerbuilder和C#gui组件。所有代码都在perforce中。

    所以我正在寻找通用语言和语言特定的最佳实践。

8 个答案:

答案 0 :(得分:7)

对我而言,#1规则是:

主要分支是神圣的 - 它必须始终是可构建的,能够通过BVT,并且基本上可用。

任何允许进入主分支导致构建或BVT中断的代码都会暴露流程中的错误。该过程应允许单个分支系统的伙伴构建/测试,或者要求子分支在合并到主分支或其他此类安全措施之前构建并传递BVT。

答案 1 :(得分:3)

答案 2 :(得分:1)

这在很大程度上取决于你建立的环境?

  • 是C / MakeFile吗?
  • 是Java / JUnit / Ant吗?
  • 是.NET / NUnit / NAnt吗?
  • 是.NET / MSUnit / MSBuild吗?
  • 是Ruby ......
  • 是Python ......
  • 是PHP

每种方法和设置都不同。因此,在您获得帮助之前,我们需要了解您的设置。

答案 3 :(得分:1)

我的头号项目:

  • 经常更新,经常提交,

或者,正如Jeff所说:Check In Early, Check In Often

答案 4 :(得分:1)

系统必须自行构建,自行测试,并自行下载+构建依赖项。 我有一个makefile下载,构建和部署运行时环境,该环境已经过我的trunk版本的“认证”。此makefile也会提交到存储库中。

记住提交另一个,非常重要且被忽视的事情(三个一组):

  • 创建数据库布局的SQL代码(在其上放置一个版本!)。
  • 调出数据库布局版本(升级)的SQL代码
  • 降低数据库布局版本(降级)的SQL代码

答案 5 :(得分:0)

如果您从“乔尔测试”中传递这些问题,那么您应该走在正确的道路上:

您是否使用源代码管理?
你做日常生活吗?
你有一个bug数据库吗? 在编写新代码之前是否修复了错误?

我的#1是:你能一步完成构建吗?

The Joel Test

答案 6 :(得分:0)

作为SCM经理,我能在这个问题上给你的最佳答案是“它取决于”。列表中项目的列表和重要性顺序取决于您的项目要求,您使用的语言以及开发人员级别。

您可能想要考虑的重要事项(或#1)在您放在一起的任何列表中,您工具的主干或主分支都受到严格控制,只有极少数人可以访问导入或提交更改。这将在发布时节省大量的麻烦。

可以放在任何列表中的项目是:

  • 何时办理登机手续(每日,每周,更频繁,更不经常)
  • 完成构建(每日,每周等)
  • 使用双重存储库(工程与生产)
  • 允许存储库中的二进制文件
  • 允许存储库中的第三方软件
  • 构建存储库所需的所有项目
  • 完成导入或提交到主干后
  • 使用一个文件导出和构建
  • 允许办理登机手续,有/无错误报告信息
  • 执行签到评论标准

列表可以根据您的具体要求不断进行,但我认为您可以了解此处的内容。

答案 7 :(得分:0)

“获得最新”和“建设”的整个过程应该顺利,简单,快速,可靠。

如果没有 - 开发人员倾向于跳过最新的并继续处理他们陈旧的副本,这是你想要避免的。

这或多或少是迈克尔所说的 - 但我想要强调的是,除了分支是神圣和稳定之外 - 整个过程应该快速而简单

有点像谷歌的理念,即下载\安装应该快速而简单