Chr*_*nte 10 javascript version-control
假设我写了一个jQuery插件并将其添加到我的存储库(在我的案例中为Mercurial).比方说,这是一个单独的文件jquery.plugin.js.我正在使用BitBucket来管理这个存储库,它的一个功能是下载页面.所以,我添加jquery.plugin.js了下载之一.
现在我想提供我的插件的缩小版本,但我不确定最佳做法是什么.我知道它应该可以在下载页面上找到jquery.plugin.min.js,但是每次我更新时都应该对它进行版本控制以反映未公开的版本吗？
我看到控制缩小版本的版本最明显的问题是,每次我对未经编译的版本进行更改时,我可能会忘记更新它.
那么,我应该版本控制缩小文件吗？
不,您不需要在源代码管理下保持生成的最小化版本.
将生成的文件添加到源代码控制(TFS)时,我们遇到了问题,因为TFS将本地文件设置为只读方式.作为构建过程的一部分生成文件的工具然后具有写访问问题(这可能不是其他版本控制系统的问题).
但重要的是,所有:
您需要构建,测试和部署产品的任何其他内容都应受版本控制.
您应该能够从源代码控制中检出特定版本(通过标记或版本号或等效版本),并完全按照该时间点重新创建软件.即使在"新鲜"机器上也是如此.
构建不应该依赖于任何不受源代码控制的东西.
脚本:构建脚本,无论是ant,make,MSBuild命令文件还是您正在使用的任何内容,以及您可能需要在版本控制下进行的任何部署脚本 - 而不仅仅是在构建计算机上.
工具:这意味着编译器,最小化器,测试框架 - 构建,测试和部署脚本工作所需的一切 - 应该受源代码控制.您需要这些工具的确切版本才能重新创建到某个时间点.
" 持续交付 " 一书教会了我这一课 - 我强烈推荐它.
虽然我相信这是一个好主意 - 并尽可能坚持下去 - 但在某些方面我并不是100%肯定.例如,操作系统,Java JDK和持续集成工具(我们使用的是Jenkins).
你练习持续集成吗？这是一个很好的方法来测试你是否掌控了上述所有内容.如果在构建软件之前必须在Continuous Integration机器上进行任何手动安装,可能会出现问题.
| 归档时间： |
|
| 查看次数： |
2017 次 |
| 最近记录： |