持续交付作为一种方法论和工具，以满足不断增长的以思想速度交付软件的需求，正迅速受到企业界的关注。持续交付（Continuous delivery）的重点是使软件始终处于发布就绪状态，是从持续集成和敏捷软件开发实践中自然演变而来的。然而，实现持续交付的文化和业务挑战要大得多。对于大多数组织来说，持续交付需要对现有的软件发布过程进行调整和扩展。整个组织中人员的角色、关系和责任也会受到影响。用于交付、更新和维护软件的工具必须适当地支持自动化和协作，为了最大限度地减少延迟并在商业组织在寻求向持续交付过渡时，应考虑以下七个先决条件-这些是切实可行的步骤，将使他们能够在监管和业务范围内成功实施文化和运营变革他们面临的限制。开发、质量保证和运营团队必须有共同的目标；并且沟通虽然持续集成将其范围限制在开发团队，但持续交付包括质量保证团队（QA）的测试阶段以及部署到由生产运营管理的阶段和生产环境团队。这是软件开发中的一个重大转变，要成功地将持续集成平台转换为持续交付平台，在其治理中集成QA和操作团队，以及让开发团队参与进来是至关重要的。协作和通信是当今成功软件开发的重要组成部分，在持续交付环境中，它必须占据中心地位。连续集成必须在转移到连续交付之前工作连续交付是连续集成的扩展。持续交付的先决条件是在项目期间进行持续集成，包括源代码控制管理、自动构建和单元测试，以及软件的连续构建。自动化和版本所有事情持续交付涉及到许多任务的连续重复，例如构建应用程序和包、部署应用程序和配置、重置环境和数据库。持续交付中的所有这些任务都应该通过工具和脚本实现自动化，并保持在版本控制之下，这样一切都可以被审计和复制。团队之间共享工具和过程是至关重要的持续交付旨在验证生产环境中使用的部署过程和自动化。要成功地做到这一点，必须尽早使用这些过程和自动化，以便在将软件部署到生产环境时对它们进行广泛的测试。在大多数情况下，相同的工具可用于所有环境，例如集成、登台和生产。The管理的操作库和质量保证程序应该是共享的，这样就可以增强团队的代码自动化。像拉请求这样的机制可以帮助治理这些共享工具和脚本。生产部署和应用程序的部署必须是非友好的，这样才能简化非生产事件部署过程。实现这一点的一个主要步骤是减少部署的组件和配置参数的数量。部署新版本时，回滚的易用性非常重要；也就是说，允许在出现问题时快速回滚。功能切换有助于将二进制文件的部署从功能激活中分离出来—回滚可以简单地说是功能的停用，这要归功于切换。特殊应注意数据库模式的任何更改，因为这会使部署和回滚更加复杂。NoSQL数据库的无模式设计模式带来了很大的灵活性，将模式的责任从数据库转移到代码。这个概念也可以应用于关系数据库。基础设施必须是项目友好型的，它将授权人员和团队。基础架构应提供所有工具（gui、api和sdk）和文档，以授权开发和QA团队，并使他们在工作中自主。这些任务包括：部署他们在环境中选择的应用程序版本管理配置参数（查看、修改、导出、导入）管理数据库（创建数据快照、恢复数据库快照）允许在应用程序日志上查看、搜索和通知警报，主要是基础设施即服务（IaaS）和平台即服务（PaaS）是项目友好平台的例子。应用程序版本必须准备好交付到产品中，持续交付的最重要目标之一是允许产品所有者决定将成功通过连续交付管道的应用程序的任何版本部署到生产中；不仅是在迭代结束时交付的版本具有"漂亮"的版本数字。达到这个目标需要对应用程序的方式进行许多更改设计：特点是未经QA团队验证的，应向最终用户隐藏。功能切换和功能分支是实现的两种关键方法这个。造工具应该从由中间未识别的快照版本分隔的语义版本的概念发展为非语义版本的连续流。Subversion存储库通过修订号帮助提供有序的版本号。Git是一种免费的、开源的分布式版本控制系统，由于其无顺序的提交散列，因此使用Git更为复杂；特殊的工具可能有助于使这个版本标识符更"易读"。关键在于，持续交付不仅仅是一组工具，它还涉及人员和组织文化。技术、人员和流程需要协调一致才能使持续交付成功；而协作方法是成功的基础。实现这些自动化的软件可以为组织提供更多的灵活性和回报也是。西里尔leclerc产品管理总监cloudbeesfollowcyrille on twitter这个博客条目最初发布在Beta新闻上。