我将对源代码控制作最后的解释。团队不应该仅仅对所写代码进行版本控制；还必须对编译与测试代码的流程（或脚本）进行版本控制。如果团队需要先前的代码，那么就可以回溯到所需的构建和测试流程。
构建自动化
自动化构建是团队用以评估当前软件或系统稳定性的第一步。而且，自动化的构建还可以降低程序花费在不必要任务上的时间，并且减少了来自开发流程的瓶颈（也就是，团队依靠于一个构建人员或一个独立的构建团队），从而实现了对于改变的更迅速的响应。
这一实践的目的是将构建流程简化为一个任何程序员都可以执行的点击一个按钮的 行为。这一行为应该包括相关系统的全部代码，不论程序员工作于什么组件或接口上。同时，系统必须能够快速编译。更快的工作站、增加的编辑和可选择的编译器可以使得编译时间更加短暂。对于程序员来说，写新代码的同时快速构建系统的能力具有许多好处。首先，它帮助程序员验证编码时设想的正确性 -- 例如，检验一个外部 API 是否如设想似的工作。其次，规则化的代码构建可以预防问题的发生。最后，它能够识别未知的很少通过本地构建显现的"远离"系统部分依赖关系。
自动化的构建将会减少团队编辑和收集问题的时间。程序员不再需要等待数小时或者执行一组费劲的任务以确信新写的代码能够编译。取而代之的是，在程序员编写代码后不久，他就能够知道是否新代码与旧有代码集成到了一起。这表示编译与集成错误将会变得显而易见，且处理起来更迅速更容易。
最后，自动化的构建对于更大系统更加重要。 大项目会继承或连接大量其它平台的系统，尤其是需要考虑有意义的联合构建流程的实际策略。在这种环境中要想获得较短的编译时间是极具挑战性的。文章的后面我将会探讨一些处理大系统构建的方法 -- 就是说，对于一个团队来说，编译与测试完整的系统并不是现实的。
自动的移植及部署
这是在自动构建之后的步骤。自动化的移植与部署行为的原因是为了精简与增强来自测试环境开发与生产环境的构建提升的可预见性。大量的问题往往来自首次引入系统测试、用户验收测试、在生产环境摸索的项目。在自动化移植中，团队可以将代码转入干净的"生产级" 环境，在那里可以执行自动化的单元和系统级测试。通过在接近生产环境下测试，团队可以在系统测试前识别出环境、集成和性能方面的问题。这样可使得团队更加熟悉实际的产品部署流程。最后，当自动化的实现了主要的产品部署流程时，就可以从公式中去除了人所犯的错误。
另一个移植与部署的重点是这些行为由一个专职团队负责管理。将这些流程集成入项目团对每日的行为中能够为各个团队带来有效及时地平衡。无可否认的是，对于大型企业来说这是极具挑战性的，因为他们的规模、报告结构和多重地理范围的因素。下面我将会更深入的探讨这一问题的解决方案。
此文章共有8页 上一页 1 2 3 4 5 6 7 8 下一页
文章来源：中国项目管理资源网
|
Leadge.com首页 > 知识库 
