supply chain management in financing

用实体经济中的供应链来套用资金供应链
不同的涉众,流通方式和渠道,管理方式,政策,风险
与实体经济的互补
电子支付是重要一环,相应还有自动清结算
让资金流动更快
无现金模式

通用指令规则(有点具体了),其实信息交换说到底就是指令.

链接:
电子支付试水企业供应链
以电子支付为切入点率先推行供应链金融线上化
支付工具升级助推企业供应链整合
当第三方介入供应链支付

Powered by MoFire

branch意味着什么

这个branch要说的是软件配置管理里的代码分支. 什么时候应该branch?为什么要branch? 一说到SCM(软件配置管理)甚至只要提到一些CVS, Clearcase,随随便便都可以找到大段大段的文章告诉我best practice. 但想找到适合自己需要的做法却还是一件麻烦事.(这时候如果在遇到一些不知道自己在干什么的人的时候,就更麻烦了)

代码分支是好事,意味着代码有了后代,有了后代意味着进化.可是有的时候代码是不需要进化的.假设就目前的系统,我们有了新的idea和实现方法,为了避开对已有代码的影响,会在”基”(main trunk)的某个版本上开辟一个新的分支进行开发 – 并行开发.这种情况下,意味着新的分支不大可能会merge会”基”.这是进化.

另一种情况,比较常见的做法,发布一个版本后,会同时生成一支专门用于bug fix,这里的前提是,你有可能会在”基”上重复发布,但有不想bug fix的东西被发布出去.这种情况下,当bug fix分支结束并测试通过后会把merge branch,之后关闭这条bug fix分支.

就我目前的知识来看,似乎只有这两种情况下 做分支才有意义.

常见的错误理解(我认为), 用分支来做平行开发,也就是把模块A用分支A,模块B用分支B. 这是典型的不知所谓.软件开发说白了管理的是依赖和变化.变化在这里暂且不提,如果两个模块有间接相互依赖,比如A依赖C,B也依赖C.这时候为了避免在模块A中对C修改会影响到B模块,做代码分支似乎解决了问题.但是既然C已经衍生出两个互不兼容的版本,就意味着你需要花很大的力气去把A中的C和B中的C合并,更可怕的是,可能仅仅因为C的两个不兼容的版本,你的两个模块被迫被发布为两个project.

如果没有这样的间接相互依赖, 那为啥还要分支呢? 这完全可以通过构建来实现.构建不出来是因为项目组织的有问题 – 依赖没搞清楚. sub-project是常见的方法来协调模块之间的依赖.

这种分支其实也ok,但谁能确保那些公用的代码不会被两拨程序员同时修改呢?如果改了,那 branch merge将变成噩梦. 如果分支时间长了,生米煮成熟饭了, branch merge的代价太大,就只能维护两套代码基了,而这两套代码基又有很多东西是相同的. yeah~

ClearCase tips

记载关于clearcase的一些常用命令:

(alias ct /opt/rational/clearcase/sun5/bin/cleartool)

1.使用view –  setview,通常是在服务器上打开已经mount的view
ct setview clsallall_dev

2.如果view没有开启,需要通过下面这个打开:
ct startview clsallall_dev

3.查找element,比如用在检查要部署的文件有没有正确放到clearcase
find ./ -version ‘{lbtype_sub(label1) && !lbtype_sub(label2) }’ -print
–列出打了label1而没有打label2的所有元素
find ./ -version ‘{version(mainLATEST) && !lbtype_sub(label1)}’ -print
–列出最新版本的元素中没有被打上label1的元素

4.打label(标签)
ct mklbtype -nc USR_BAU_SRXXX

关于版本管理的一点总结

这是最近几天研究的一个关于配置管理,变更管理,发布管理的简单流程 – 根据我们目前的情况和需求.用到了clearcase的细节就不说了.把流程图先发上来.这个图着重指出的是change coordinator的practice.

相关资料:
Common ClearCase Practices

High-level Best Practices in SCM

Clearcase Versioning[PDF]