贵公司如何部署其软件？

我目前正在进行一项简短的研究项目.我工作的公司有一个非常繁重的发布过程,随着时间的推移越来越严重.我们在每个版本中遇到越来越多的问题,这些问题开始严重影响我们的交付时间表和每个版本的质量.我们提供了一个大型SAAS产品,该产品在一个非常大的Web场上部署到Internet.我们的部署流程目前由专门的团队处理,开发人员参与最少.我们主要是.NET商店,但我们也有几个Java组件.

我正在研究如何改进我们的质量保证和部署流程,以减少浪费,并将更多的流程纳入我们的开发团队.我有兴趣了解贵公司如何将您的产品(最好是SAAS,但不仅限于此类产品)部署到生产中,以及通过测试途径进行生产.我很好奇什么有效,什么没有,我相信很多人都有故事可讲.

编辑(附加RFC):

在我继续研究的过程中,我遇到了"持续部署"的概念,显然是由IMVU 3d在线社区团队开创的.这听起来像一个有趣的概念,如果可能有点复杂.我很好奇,如果SO上的任何人有持续部署的经验吗？特别是一个大型,复杂的项目,它有很多部分.你不一定必须不断地部署到生产环境......我们的短期需要,我们只会看看持续部署内部开发/ QA/perftest环境.如果有人实施了持续部署,我也很想知道如何管理数据库架构和数据更改/回滚.

谢谢!

我们将金融服务SaaS解决方案部署到Amazon AWS云环境.我们的解决方案是100%Java,因此许多工具不适用于您,但概念应该适用.

首先,当通过运行持续集成过程进行发布时,我们减少了意外数量.任何时候任何开发人员签入源代码,整个解决方案都会自动构建,所有单元测试都会自动运行.失败通知将通过电子邮件发送给相关开发人员和团队负责人.

AWS围绕虚拟机的概念构建.我们通过创建一个虚拟机映像利用这一点(Amazon称之为AMI的),包含操作系统和应用程序(Java中,DB等)的特定版本是我们的愿望.构建过程会创建所有可部署的工件,然后根据该AMI将它们复制到正在运行的实例.这适用于所有环境(测试,演示,PROD)完全相同的过程中,除了封装版本的差异(例如连接字符串)一个配置项目.

QA在TEST环境中测试结果.一旦他们同意的版本,我们重复构建过程瞄准PROD(使用完全相同的版本控制修订.请记住,每个环境之间的唯一区别是一个配置的项目).

此时,我们使用PROD代码库创建在基本AMI上运行的虚拟机(实例),并将其称为STAGING.STAGING经历了一系列自动和手动验收测试.这是非常好的部分......现在,我们将此环境(基本AMI加上我们的应用程序的新版本)刻录到新的 AMI(虚拟机映像)中.然后我们基于这个新映像创建我们的应用服务器的新运行实例,更新负载均衡器以指向这些新实例,并且只是杀死旧实例.这就是使用虚拟机的美妙之处(至少,这是美女之一).

每当我们需要调整容量(高峰时段/天)时,我们都会从同一个生产AMI创建新的应用服务器实例,并将其注册到负载均衡器.当峰值结束时,我们只是从负载平衡旋转中删除它们,然后在几分钟后终止额外的实例(以允许现有会话完成).