完成部署vs超出部署 [英] Complete Deploy vs Out of Cycle Deploy

问题描述

我不知道如果你们中有任何人遇到这种情况。我们有小的小项目或
修复，我们需要推送到LIVE每隔一天。

有一组团队说做一个干净的构建并在prod服务器上部署。
另一个集合说我们不需要完全部署，我们只会做一个dll drop或者aspx drop。

他们列出了每种方法的优缺点。但是想知道你通常遵循什么方法来对每个方法进行任何主要设置。

解决方案

我将首先尝试最小化通过尝试尽可能自动化构建新版本的成本。 （这可能比说起来容易一些，但通常投入很多时间和金钱，特别是如果您经常发布）。

我在新的二进制文件中丢弃了一大问题这是通常是一个手动的过程，而这些是由人们执行的，这些人往往会一遍又一遍地弄乱这些简单的任务。

你不是真的在寻找一个补丁管理系统可以帮助您以受控的方式分发变更并摆脱手动工作？

这样，您仍然会有非常好的完整性，因为补丁应该被版本化，并希望仔细测试。但是，仍然可以开发和部署更少的开销，然后完全释放。

I'm not sure If any of you have encountered this scenario.We have small small projects or fixes that we need to push to LIVE every other day.

There is one set of team that says "do a clean build and deploy on prod server". The other set says we don't have to do a full deploy we will just do a dll drop or aspx drop.

They have listed out few pros and cons for each method. But want to know what method you generally follow any major set backs for each method.

解决方案

I would first of all try to minimize the cost of building a new release by trying to automate as much as possible. (Which might be easier said than done but it is usually well invested time and money, especially if you release often.)

The big issue I have with dropping in new binaries is that it is often a manual process and those are performed by humans who tend to mess up the easies tasks over and over again.

Aren’t you really looking for a "patch management system" that could help you distribute the changes in a controlled manner and getting rid of the manual work?

That way you still would have pretty good integrity since the patches should be versioned and hopefully carefully tested. But still they can be developed and deployed which much less overhead then a full release.

这篇关于完成部署vs超出部署的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！