这些天无论你怎么看，像敏捷开发这样的术语是否似乎已经被抛弃了？有些IT人员似乎与敏捷开发一起吃、睡和呼吸。他们在Quiznos点一份三明治，很可能甚至会做多个创建和测试的替代，这会使员工疯了的。不过，你不必成为一个敏捷开发的狂热者，承认该方法在软件项目管理领域有许多有用的特性。这不仅仅是为了规划、设计、开发和测试等等。部署策略也可以从敏捷开发策略中获得利益。这些有一些小技巧，可以在作用下一个敏捷开发部署时提供帮助。

    敏捷开发需要自动化

    在现在世界中，敏捷开发使用者经常把大部分注意力放在加速部署时间和部署频率上。但可能忽略了部署的实际流程。这可以在IT操作方面很让人头痛。他们是支持努力部署完一个新的版本，再部署另一个的一群人，但却经常很匆忙（并提高了错误的风险）因为有一个巨大的待办事项列表要处理。

    在一个星期，而不一个月内开发生产并没有太多的好处，如果它在操作中在“发射台”上呆了几周的话。这就是为什么操作必须提供自动化工作，并经常重做部署行为。幸运地，后面的敏捷开发迭代通常与前一个版本类似，这意味在每一件事中都存在很大的重用的可能性，从批处理脚本到安装脚本。理想地，操作应该把它的部分精力和智囊团放在主要生产版本上。

    锁定和负载

    如果你每周都做部署，给开发和部署团队设定日程安排会很有好处的。IBM描述了它缩减周期时间的流程，通过引入定时迭代给部署团队。如果希望开发团队在每个周一的上午9:00提供代码。那么部署团队就要在周一到周四进行部署（先是状态，再是生产）。开发团队确切地知道有多少部署资源分配给了该项目，并可以决定出每周部署什么是最重要的。这帮助他们高效的集中努力工作并相应地资金积累部署包。[page]
    持续敏捷开发部署

    敏捷开发部署可能被视为是另一个简单的测试步骤，因为多开发部署在生产和部署之间执行。QA（质量保证）“用户”深入参与改进系统提供频繁的反馈。这不只是系统或组织满园的部署。把代码部署的QA或测试环境，对特殊用户可访问，以及尽可能地接近真实世界环境。这种方式下，用户可以进行持续测试以及返回进行改进。有些情况下，在生产中可能会实际添加一些补丁。或者，产生可能会发送回去，在开发中进行更多迭代。另外，有时，在最终环境对限定数量的终端用户进行试用或测试部署可能也会对实际使用情况做到更大的洞察。

    期待生产

    因为你的软件也实际系统是否可运行它相关，所以当你计划和开发软件时，应该考虑一下生产环境。这有助于在开发中避免尴尬的失误。没有什么事情可以让敏捷开发使用应用程序准备好出发，但又发现它置于产生端的话就不能与设备很好的工作。

    文档要在最后

    使用敏捷开发，你很难知道最终产品会是怎样的，直到你实际进入到发布阶段。这意味着事先制作大量的项目文档是很蛮干的--你需要重做他们中的大部分。因此，开发期间做足够的文档来保持一切井然有序并能跟踪。在制作详细、准确版的文档，作为最终流程的一部分。理想情况下，您应该记录部署流程，以及支持程序和用户指令。这一领域需要开发、操作和支持共同合作，以确保其准确和成功。如果是做敏捷开发部署，你只需做足你的利益相关者要求的敏捷开发文档即可。

    还没结束

    在敏捷开发世界，部署没有终点。它被视为是一个流程。即使你打算做更多的传统的瀑布式的软件项目管理，这可能是一个采取的有用态度。你仍然在测试、测试，但是你知道，上线日期之前并不是所有东西都是绝对完美的。这里或那里的一些小错误不能被视为失败。把获得的反馈作为短时间内改进和部署更好版本的一种方法。只要做好准备，实际上让这些改进跟进；敏捷开发永远不应该被用作是劣质的工作的借口

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。