关于发布的问题

问题一般可以从两个方面考虑解决方案：管理和技术；
管理层面通过制定流程和规则规范人的行为；
技术层面通过一定的技术尽量把人解放出来；
很多时间单以管理或技术都难以达到效果，必须双管甚至多管齐下，现在我们面临的发布问题目前就是这样一种情况。自从09年进公司到现在，发布上的问题个人觉得还是有所改善，记得当时经常发布搞到晚上十点十一点那是太正常的事情，而且我们的配置管理同学也会不厌其烦的把那些发布失败的需求重新再发一次。大家都在发布这辆车上前前进进，后后退退，经常由于一个人的问题导致整辆车退回去重来，一天往往复复好几次。后来制定了相应的流程和方案，提出了定时必须上车，否则下车不准再上的规则，相对以前还是好多了。但是最近的发布好像又非常不顺利，这也说明，单单从流程上面是无法根治这个问题的！大家也都尽情讨论产生这种问题的根源以及相应的对策。从大家邮件里面总结出来主要原因是：各个应用依赖关系复杂、公共库版本管理问题、发布模式原始和发布者不够上心。具体的对策是：理清依赖关系，采用新的发布模式等。大家从各个角度和层面针对问题提出了相应的解决方法，而且很多同学提出的方法和指出的问题都很本质，让我受益匪浅。
但是产生发布问题最根本的原因我认为：首先是人的问题、其次是业务存在问题才会诱发发布的问题；发布回滚的直接原因是发布的需求存在质量问题，为什么质量问题不能尽早扼杀在开发或者测试中，可能是开发粗心可能是测试漏测，或者应用庞大历史遗留的雷被踩。但是不管怎么样，只要努力用心做，这些应该还是可以避免的。另外，从一个软件的生命周期来考虑这个问题，软件方面很多问题的根源还是在于业务的问题；发布为什么会纠结，代码库依赖为什么会混乱，因为我们的业务本身就是混乱的，我们业务划分不够清晰，业务分工不够明确，业务分工模式也存在问题。在业务混乱的情况下，代码结构、应用相互依赖他能不混乱吗？业务上存在问题才会导致留下很多雷，才会隐患重重。做新业务的时候首先把业务理顺，业务结构理清楚，业务也要分层次；后面的代码能理顺。代码顺了，发布自然也不会存在问题。
总的来说现在的发布问题，应该是我们对历史的一次回顾和总结，其中可以吸取不少教训。
自己的一个感想：程序员的功过只能交由后人去评判 。