.net - 贵公司如何部署其软件？

Question

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

我正在研究如何改善质量保证和部署流程，以减少浪费，并将更多流程纳入开发团队的领导之下。我很想了解您的公司如何将您的产品(最好是SAAS，但不限于此类产品)部署到生产中，以及在此过程中进行测试的过程。我很好奇什么成功了，什么没有成功，我敢肯定你们中的许多人都有故事要讲。

编辑(其他RFC):

在继续研究的过程中，我遇到了“持续部署”的概念，该概念显然是由IMVU 3d在线社区团队率先提出的。听起来有些有趣，甚至有些复杂。我很好奇，SO上的任何人是否有持续部署的经验？特别是对于一个大型，复杂的项目，其中包含许多部分。您不一定非要持续部署到生产环境中……出于我们的短期需求，我们只希望将持续部署部署到内部dev/qa/perftest环境中。如果有人实现了持续部署，我也很好奇您如何管理数据库架构和数据更改/回滚。

谢谢!

Answer 1

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

首先，我们通过运行连续的集成过程来减少发布时的惊喜数量。任何时候任何开发人员 checkin 源代码时，都会自动构建整个解决方案，并自动运行所有单元测试。失败通知将通过电子邮件发送给有问题的开发人员和团队负责人。

AWS是围绕虚拟机的概念构建的。我们通过创建一个虚拟机镜像(Amazon称为AMI的虚拟机镜像)来利用它，该镜像包含所需的特定版本的OS和应用程序(Java，DB等)。构建过程将创建所有可部署的工件，然后将它们复制到基于该AMI的正在运行的实例。除了封装了版本差异(例如连接字符串)的单个配置项目外，所有环境(测试，演示，PROD)的过程都完全相同。

质量检查在TEST环境中测试结果。一旦他们批准了版本，我们将针对PROD重复构建过程(使用完全相同的版本控制修订版。请记住，每个环境之间的唯一区别是一个配置项目)。

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

每当我们需要调整容量(高峰小时/天)时，我们都从同一生产AMI创建新的应用程序服务器实例，并在负载均衡器中注册它们。高峰结束后，我们将其从负载平衡循环中删除，然后在几分钟后杀死多余的实例(以允许现有 session 完成)。