架构研究室

使用版本控制的分支合并进行开发,模拟,运营环境的统一部署

参考文档
http://www.subversion.org.cn/svnbook/1.4/svnbook.html

为了运营环境的发布管理
我们会使用版本控制软件
来将所有发布在运营环境的内容进行系统管理
以保证能够及时的回滚到前一个发布状态
但是当流程链涉及到跨部门合作时
我们如果仍旧只是简单的分割管理层次
在不同部门之间使用简单文件传输进行沟通
就会导致比较大的沟通损耗
特别当一次发布内容比较多时
运维发布的操作就会特别琐碎
开发需要保证找出所有需要发布的内容,按照原来路径位置和目录打包
而运维则需要保证所有文件按照文档的所标识的位置覆盖或者新增文件
这这种发布文档.最大面临的问题就是文件有缺少或者位置错误.
而且这种开发环境以及运营环境独立的模式.
会导致需要在各个环境保持一台独立的版本控制服务器来保存各种副本.

如果是涉及到整个开发运营流程
我们可以只使用一套SUBVERSION服务器进行对一个项目的分割管理
在同一个项目内建立不同的分支
而在需要发布时,由开发将需要正式发布的内容合并至发布分支
运营环境直接从发布分支中获取更新后的程序发布即可
这样在整个流程链中.可以保证不会由于目录写错或者文件名写错等等导致的发布问题
因为开发环境的目录和分支后的发布目录的路径是一致的.
再复杂的目录也不会因为人为的目录书写问题而出错,因为其中不需要人为去书写目录以及文件名

整个流程如下
1.建立两套服务器.配置一直.程序发布的目录等设置也保持一致
2.其中一套作为开发测试环境使用.一套作为对外公布运营使用
3.建立SVN Repository,建立trunk目录作为主代码分支(本人习惯使用develop或者maincode.这个按照实际情况可以更换.),建立branch目录作为其他分支(这里我使用release目录作为发布分支).
4.开发人员使用develop分支进行开发,开发测试环境使用此分支进行同步.在模拟环境内进行测试.
5.当开发人员确认某个测试版本稳定后.将develop分支的内容合并(merge)到release分支.
6.运维组将release分支的内容update到运营环境中.

操作详解与注意事项
1.建立代码树的时候.把最初的源代码放在repository的一个分支目录下.而不要放在根下.否则会对做分支造成很大的困难.
例如本例中.开始的文件存放在svn://61.142.253.163/test这个repository下的develop目录下.

2.签出代码
在开发人员的PC上
建立目录
进入目录
选择SVN checkout
输入svn repository节点地址
输入用户名和密码

3.创建分支
在开发目录中选择Branch/tag

在To URL中选择需要创建的分支

4.合并
在开发客户端上新建立一个目录
将release分支的内容update到新目录
在release目录内选择Merge

然后在上面From中选择需要从哪个分支合并过来

选择起始revision号
默认在To中的分支和From分支应该是一致的
选择结束的revision号.
则这段之类commit的内容
都会合并到目前的目录内
点击merge
合并结束后本地release目录已经包含了从develop分支合并过来的内容
然后再本地目录commit.将合并后的内容提交到release分支上

5.从开发树中抽取文件更新到发布树
目前的流程会面临一个问题
就是当一个开发人员在develop分支内一次提交的内容即包含bugfix,又包含特性增加
则这次revison内的内容无法单独提取出来去更新release分支
因为可能运营环境需要增加的只是一部分bugfix
当然这个问题也能够通过更细致的分支操作来解决
即是每个开发人员对于bugfix以及特性增加
都有不同的分支树来处理.而之后再分部分的合并到develop分支上
而测试通过之后.可以将区分的内容去合并到release分支上
就是开发人员每次提交的内容如果不属于同一部分
是不允许一次性同时提交的.
另一个解决这个问题的方法
是在开发树中show log

然后选择对应revison中的对应文件.选择save revision to
将保存的文件覆盖发布树的对应文件

这样从一次混杂着bugfix以及新特性增加的commit中提取需要内容来做更新的操作
就可以顺利完成了

成功者的个人英雄主义

在别人的博客上
我看到有讲述团队合作的授权
里面有一条
“领导的个人英雄主义只会扼杀员工的创造力”
我觉得这事情要两方面来看
领导必须有个人英雄主义
这样才会有个人魅力和团队的凝聚力
才能把领导的热情.散播到周围的每一个人身上
只有将团队成员都集中在你周围
觉得你把事情委任给他是一种荣耀时
这种授权才会激发成员的创造力
体现他的个人价值
而好的领导
会把这种热情
转换成企业的英雄主义
这就是为什么MS,GOOGLE这么吸引人的理由.
一些知名的大企业
他的创始人,无不是个性张扬的
没有他们的个人英雄主义.是没有人被他们的这种霸道所吸引的.
人就是这样.希望自由.但是有时候又会崇拜偶像.

秉承6星职业素养－新、信、行、馨、型、星

    新。很显然，指的就是不断学习，接受新知识、新理念，在工作中敢于突破自己，不因循守旧，不把以往的辉煌和成就用来重复延续今后的工作，面对市场环境的千变万化，时时刻刻要保持创新的本能和激情。
    信。一个人做事当然前提是要诚信，另外，瞻前顾后、畏首畏尾是不会有多大出息的，关键是要树立信心，坚定信念，拥有良好的心态，碰到问题要沉着冷静，培养较强的承受能力，通过多方努力予以解决。事实上，倘若自身都没有信心，那怎么会有机会来光顾你呢。
    行。再好的策略和思路都需要通过执行来达到目标，所以，一个人如果要想成功，就必须赶快行动，否则，时不我待，光空想和抱怨是无济于事的。
    馨。作为一个开放型社会，许多企业都在服务客户上狠下功夫，同样，你如何在工作中体现你人性化、生动化的服务，形成自身的良好口碑，给客人带去关怀和问候，把服务细节落到实处，这是大有讲究的。
    型。无论是对外交往还是置身于一个团队，自己要特别注意形象礼仪，因为一个有型有款的人士往往会给人带来亲切并容易接近的印象，这对自身的结交人脉、提升业绩大有裨益。
    星。通过打拼实现自己的价值，要敢于成为行业明星，因为只有这样，才有充分挖掘潜力，才有最终走向成功的可能。

从盖茨退出而引出的软件开发模式的变化

互联网不光具有传统的网络效应，而且它是分布式的，是以节点为中心的。
对应的商业模式和技术路线，必然导向个性化、定制化。这就是WEB2.0的特点。
微软已经改不过来了，因为工业化生产方式的烙印，已经从盖茨到整个团队，深深嵌入了。
其一，它是一个以生产者为中心的公司，它只能有限地以消费者为中心，而不可能象谷歌那样，从生产方式本身上就是以消费者为中心的；
其二，以生产者为中心，必须导致集中计算模式的技术路线。微软现在还在坚持操作系统升级的思路，沿着惯性在发展，而这种技术路线，与搜索引擎、P2P等格格不入；
其三，集中到操作系统进行计算的模式，已经产生了一种大型化的利益模式，如WINTEL联盟这样的利益模式，这种模式不可承受生命中个性化之轻，没有几十亿的利益，根本不值得为之启动什么正经项目。

这段话阐明了WEB 2.0时代的软件业格局的变化
以及今后软件公司需要应对的局面
如果还停留在生产者的状态
并且无法对用户的需求做出及时反应
则软件供应商很容易被用户抛弃
近几年的开发模型的变化,例如极限编程等等的崛起
以及表现出高速开发的重要性了.
在面向普通用户市场时
BUG已经显得不是非常重要了.只要能够及时修复即可
网游以及网站程序的开发模式
已经能够为很多用户所接受
而一成不变的软件,除非用于专业领域
否则将越来越赶不上这个时代的趟.
人们几乎无法接受一个3个月都没有更新的软件
而开源软件的开发模式
也是对应了这个时代的需求
快发布,快更新,快响应
软件测试人员的工作
也将慢慢转由最终用户来做.
原来的一部分软件测试人员
将升级成为DEBUG程序员.

项目拯救之道

项目失败的原因:
1.对项目的现状没有清晰的了解,都是估计或者猜测
2.对于项目状况过度乐观
3.无法控制项目的进度情况
4.项目定义过于潦草,没有清晰的项目目标
5.项目先期预估存在重大偏差

项目拯救步骤:
1.暂停项目
2.评估项目现状
3.重组项目团队
4.重设项目目标
5.设置项目监控
6.重启项目

项目拯救必须条件:
1.高层的绝对支持和明确表态
2.合格的评估者,评估者的专业水平以及客观性影响拯救结果
3.制定完整计划并且严格遵守,防止启动后的拯救计划同项目原先一样延期.

教育领导的问题

在很多情况下
指挥一线工作者的人(一般是主管层以上)
往往不会拥有更多的专业知识
相反
越高层的领导.专业知识越薄弱
但是最终决策者
却是他们
如何教育领导
让他们按照专业的思考方法去思考问题
就是所有摆在一线工作人员面前的问题了.
这种情况下.建议不要和他们谈理论.用一些实际来说明
比如进行一次可用性测试
当领导发现实际用户完全不是按照他们的想法来评论他们的理念的时候.
他们才会知道自己的意见并非那么好.

How To Make a Team Work

1.Recognize That People Who Work For You is Most Importent

2.Give Your Member One Target

3.Give Users Feedback To Your Member

4.Keep Member in Progress of Project

PS:感觉用英文来写会有一种强烈性的表达效果,
所这里这里INSTALL 一下B.

员工归属感研究

员工的归属感
产生自员工对于自身工作的自豪感以及使命感
而自豪感
源自员工所从事的工作是否可以被用户承认
这种承认从来不会来自于某领导或者高层简单的夸奖或者拍肩膀
虽然领导的认可可以在一定时间内给予员工一定的正面作用
但是没有实实在在的源自于最终用户的认可和反馈
这种正面作用往往会很快消逝
所谓职业生涯规划等等
本身是脱胎于员工所在工种的发展,以及项目可带给员工的发展
没有实际工作中的正反馈
员工职业生涯规划犹如画饼充饥.就好象你对一个乞丐说明天如何去当上总统一般的不切实际
所以公司要让所有员工,知道公司项目的进度和受关注程度
我们很多做IT的都会开玩笑说
即便是到了GOOGLE,BIZZARD,或者MS,哪怕是去沏茶倒水也好.
其原因就是由于即便去做和这些公司项目并无直接相关的工作
那种实在的工作和项目的实际效果之间的隐形关联
也会被员工作为自己的贡献而感到自豪和成功
而这种成功感
对于公司来说就是更高的凝聚力
就是”哪怕我能去XXX,即便是不要工资也可以”的吸引力

PS:本BLOG的101篇文章,希望我能够踏上更高的一个层次去考虑问题

领导层应该避免的问题

1.忽略员工对于成功的渴望,没有将公司的进步及时反馈给员工
2.无法将其想法和展望传达到下属的每个员工
3.高高在上,坐在单独的办公室内,要属下对其恭敬,由此产生隔阂而不自知
4.过分的指导细节却无法对全局进行把握
5.对自己不擅长的方面指手画脚,过度干预
6.完全放手不对项目进行任何监控,过度放手
7.太严厉或者太和善
8.经常以管理者的身份强迫下属做其不愿意做的事情