极客观点
项目管理
HarmonyOS
本主题的关键词：软件生命周期管理(Application Lifecycle Management)、变更管理(Change Request Management)、传输控制(Transport Control)
以下关键词和本主题不直接相关：配置管理(Configuration Management), 问题追踪(Issue Tracking)
尽管这些和ITIL原则更紧密相关，但我猜以快速创新为主导的互联网公司大概不愿“墨守成规”，而选择祭出自己的全盘解决方案。事实上无论你的项目/企业是否实践了ITIL，随着软件系统规模上升（或与之相对的系统环境变得复杂），在开发/运维项目中很可能面临以下问题：
1、许多项目环境需要引入某种形式的变更管理工作流，或者说所有的变更需要经历多个阶段（比如开发、测试、生产上线）以及相应的许可批准从而进行至下一阶段。这一问题通常被称为变更管理(Change Request Management)。
变更可以是开发系统上的某个配置更改，某个代码commit或是若干bug fix的集合；变更具有不同类型（来适配对应的生命周期）；变更可以来源于某个issue，或是某个新功能需求。变更管理会涉及特定的人员角色如变更经理(Change Manager)等履行不同的职责。 (http://projects.puppetlabs.com/projects/1/wiki/Change_Management)
构建这一流程的优势在于：减少变更对于业务的影响、增加变更的透明度和沟通、减少可能的变更撤销、适应大规模的变更、为进行影响分析（impact analysis）提供可能
Q:在你的项目经验中，对于变更的管理是否应用了简单的issue tracking之上的具体流程？
2、我会假设一个软件项目的系统环境是三层系统架构：开发(Dev)——测试(QA)——生产(Prod)。在现今互联网应用前所未有复杂，对业务空前重要的情况下，在部署系统更新或例行配置更改时我们必须保证配置或更改对于所有特定的环境（数据库，Web Server、Application Server或者Middleware Container）都是正确的；然而，如果存在一些没有列入文档、不遵循流程的手工更改，要识别一个在QA系统上测试通过的应用和在生产环境上的那份程序是不是相同版本会很困难且容易出错。而且撤回上一次更改重新迭代的情况也屡见不鲜。
再者，假设我们可以始终将开发系统与生产系统的程序代码update到同一个正确的commit或branch来进行更新，仍然需要考虑是否会存在系统间其他配置或应用所需数据的不一致性（那些无法简单通过Git、SVN进行版本控制的部分）。
Q: 那么在开发或运维过程中，你在部署变更时，代码、配置、数据的更改是如何进行传输的——换言之就是——如何控制这三层架构的所有系统的一致性，以及如何控制每层上大量系统间的一致性，也就是传输控制(Transport Control)。每个变更是通过增量形式传输的吗？是自动化识别还是手工维护的？
3、联动http://www.v2ex.com/t/134406 这帖中的需求其实是构建一个生命周期管理流程（ALM），并进行自动化。典型的ALM系统是一种提供建立模型、部署（至多种基础架构）并管理应用的平台。
Q:在你的项目经验中，是否应用了这一流程相关工具？是否实现了某种相关需求的自动化（为Nightly build等需求提高部署效率）？
即使在企业没有应付auditing的需要，一旦系统规模上升到一定水平，全盘依赖简单的issue tracking系统+手工处理的风险就会异常的高。虽然例如puppet, chef等配置管理工具已经被广泛应用在互联网企业软件项目中，但关于ALM和变更管理的内容在全套的ITIL解决方案之外却很少被提及。我相信一定有若干已经形成的流程被应用于其中来解决一些显著的问题比如：在快速迭代开发的过程中，如何保证项目环境内各系统之间代码变更的一致性等。
我很好奇在你所经历的项目场景中，这些工作是如何开展的：）
这么专业的问题，你肯定自己就有一套答案了吧:-)
简述:
借助与jira系统，可以实现大部分你提到的项目管理、需求变更等。
测试环境可以分多套，除了开发环境外，以我们的项目为例，还会有3个测试环境，分别对应local，uat,qa阶段。
local的测试完成后，会部署到uat，直至最后被用户认可后，进入发布环境qa，最后进入产品环境。jira上的issue svn提交后，会自动合并，部署到相应的测试环境
至于配置，因为各个环境都不一样，分别维护不同的配置项。
发布工具（jenkins )，自动每天定时部署。