blocks|key|339144|text|web安装/安装项目-因此，如果出现问题，您可以轻松地将其卸载|type|unstyled|depth|inlineStyleRanges|entityRanges|data|339145|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

web setup/install projects - so you can easily uninstall it if something goes wrong

blocks|key|3101231|text|我们使用Setup+Factory将所有代码部署到MSI中。如果需要更改，我们会重新部署整个解决方案。这听起来像是对css文件的过度杀伤力，但它绝对保持了所有环境的同步，并且我们确切地知道生产环境中是什么(我们以相同的方式部署到所有测试和uat环境)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3101232|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

We have all of our code deployed in MSIs using Setup Factory. If something has to change we redeploy the entire solution. This sounds like overkill for a css file, but it absolutely keeps all environments in sync, and we know exactly what is in production (we deploy to all test and uat environments the same way).

blocks|key|3101385|text|早在2009年，这个答案就来自于此，我们使用CruiseControl.net进行持续集成构建，这也输出了发布媒体。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3101386|在此基础上，我们使用Smart+Sync+software与超出负载平衡池的生产服务器进行比较，并将更改上移。|offset|length|3101387|最后，在验证了发行版之后，我们运行了一个主要使用RoboCopy将代码同步到实时服务器的DOS脚本，在运行过程中停止/启动IIS。|3101388|entityMap|0|LINK|mutability|MUTABLE|url|http://www.smartsync.com/^0|0|A|J|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@$D|R|E|S|1|T]]|A|$]]|$1|F|3|G|5|6|7|U|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]]]

Back in 2009, where this answer hails from, we used CruiseControl.net for our Continuous Integration builds, which also outputted Release Media.

From there we used <a href="http://www.smartsync.com/" rel="nofollow noreferrer">Smart Sync software</a> to compare against a production server that was out of the load balanced pool, and moved the changes up.

Finally, after validating the release, we ran a DOS script that primarily used RoboCopy to sync the code over to the live servers, stopping/starting IIS as it went.

blocks|key|3101390|text|用于ASP.NET的简单XCopy。压缩它，sftp到服务器，解压缩到正确的位置。对于第一次部署，手动设置IIS|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3101391|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Simple XCopy for ASP.NET. Zip it up, sftp to the server, extract into the right location. For the first deployment, manual set up of IIS

blocks|key|3101452|text|我们对实时服务器进行滚动部署，所以我们不使用安装程序项目；我们有更像CI的东西：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3101453|3101454|“实时”构建-从认可的源(不是存储库的“头”)|unordered-list-item|offset|length|style|BOLD|3101455|(在它进行了备份之后；-p)|3101456|robocopy发布到临时服务器(“实时”，但不在F5群集中)|3101457|最终验证在临时服务器上完成，通常使用“主机”黑客来模拟整个过程，就像使用possible|3101458|robocopy+/L自动分发下一次“推送”中的更改列表一样，以提醒任何goofs|3101459|作为计划进程的一部分，群集被循环，通过robocopy部署到群集中的节点(当节点不在群集中时)|3101460|3101461|robocopy自动确保仅部署更改。|3101462|Re的应用程序池等；我喜欢这是自动(see+this+question)，但在目前它是手动的。不过，我真的很想改变这一点。|3101463|(我们有自己的数据中心和服务器场“现场”可能会有所帮助，所以我们不需要跨越太多障碍)|3101464|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/965330/developer-tool-for-configuring-iis6^0|0|0|8|3|0|0|0|0|0|0|0|0|D|1C|I|H|0|0|0|16|0^^$0|@$1|2|3|4|5|6|7|18|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|19|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|1A|8|@$F|1B|G|1C|H|I]]|9|@]|A|$]]|$1|J|3|K|5|E|7|1D|8|@]|9|@]|A|$]]|$1|L|3|M|5|E|7|1E|8|@]|9|@]|A|$]]|$1|N|3|O|5|E|7|1F|8|@]|9|@]|A|$]]|$1|P|3|Q|5|E|7|1G|8|@]|9|@]|A|$]]|$1|R|3|S|5|E|7|1H|8|@]|9|@]|A|$]]|$1|T|3|-4|5|6|7|1I|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|1J|8|@]|9|@]|A|$]]|$1|W|3|X|5|6|7|1K|8|@$F|1L|G|1M|H|I]]|9|@$F|1N|G|1O|1|1P]]|A|$]]|$1|Y|3|Z|5|6|7|1Q|8|@$F|1R|G|1S|H|I]]|9|@]|A|$]]|$1|10|3|-4|5|6|7|1T|8|@]|9|@]|A|$]]]|11|$12|$5|13|14|15|A|$16|17]]]]

We do rolling deployment to the live servers, so we don't use installer projects; we have something more like CI:

<ul>
<li>"live" build-server builds from the approved source (not the "HEAD" of the repo)</li>
<li>(after it has taken a backup ;-p)</li>
<li>robocopy publishes to a staging server ("live", but not in the F5 cluster)</li>
<li>final validation done on the staging server, often with "hosts" hacks to emulate the entire thing as closely as possible</li>
<li>robocopy /L is used automatically to distribute a list of the changes in the next "push", to alert of any goofs</li>
<li>as part of a scheduled process, the cluster is cycled, deploying to the nodes in the cluster via robocopy (while they are out of the cluster)</li>
</ul>

robocopy automatically ensures that only changes are deployed.

Re the App Pool etc; I would love this to be automated (<a href="https://stackoverflow.com/questions/965330/developer-tool-for-configuring-iis6">see this question</a>), but at the moment it is manual. I really want to change that, though.

(it probably helps that we have our own data-centre and server-farm "on-site", so we don't have to cross many hurdles)

blocks|key|334329|text|回答你的问题：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|334330|334331|XCopy|ordered-list-item|334332|Manually|334333|For静态资源，我们只部署发生变化的资源。|334334|334335|对于动态链接库，我们部署更改后的动态链接库和ASPX页面。|334336|是，是的。|unordered-list-item|334337|334338|到目前为止，保持它的良好和简单已经为我们省去了很多麻烦。|334339|entityMap^0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|V|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|W|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|X|8|@]|9|@]|A|$]]|$1|H|3|I|5|E|7|Y|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|10|8|@]|9|@]|A|$]]|$1|M|3|N|5|O|7|11|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|12|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|13|8|@]|9|@]|A|$]]|$1|S|3|-4|5|6|7|14|8|@]|9|@]|A|$]]]|T|$]]

Answering your questions:

<ol>
<li>XCopy</li>
<li>Manually</li>
<li>For static resources, we only deploy the changed resource. 
 For DLL's we deploy the changed DLL and ASPX pages.</li>
<li>Yes, and yes.</li>
</ol>

Keeping it nice and simple has saved us alot of headaches so far.

blocks|key|336841|text|我将大部分ASP.NET应用程序部署到Linux服务器上，并重新部署所有应用程序，即使是最小的更改。以下是我的标准工作流程：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|336842|336843|我在服务器上使用源代码存储库(如Subversion)|unordered-list-item|336844|，我有一个example)|336845|Backs脚本，它执行以下操作：|336846|签出最新的代码|336847|执行构建(创建database|336848|Deploys+)|336849|将文件筛选到最基本的部分(删除hit|336850|336851|的代码文件将文件放到以当前日期命名的目录中的web服务器)如果deployment|336852|Makes中包含新模式，则|336853|
|336854|将更新数据库新安装默认安装，以便在下一个DLL中使用它|336855|336856|​|336857|签出是使用Subversion的命令行版本完成的，构建是使用xbuild+(类似于Mono项目的msbuild)完成的。大多数魔术都是在ReleaseIt中完成的。|336858|在我的开发服务器上，我本质上是持续集成的，但在生产端，我实际上是通过SSH连接到服务器，并通过运行脚本手动启动部署。我的脚本被巧妙地命名为'deploy‘，这就是我在bash提示符下输入的内容。我很有创造力。不。|336859|在生产环境中，我必须键入“deploy”两次:一次是签出、构建并部署到一个过时的目录，另一次是将该目录设置为默认实例。由于目录已经过时，我可以通过在相关目录中输入'deploy‘来恢复到以前的任何部署。|336860|初始部署需要几分钟，恢复到以前的版本需要几秒钟。|336861|对我来说，这是一个很好的解决方案，它只依赖于三个命令行实用程序(svn、xbuild和releaseit)、DB客户端、SSH和Bash。|336862|我真的需要在某个时候更新CodePlex上的ReleaseIt副本：|336863|http://releaseit.codeplex.com/|offset|length|336864|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|0|0|1|1|1|1|1|0|0|0|0|0|0|0|0|0|0|0|0|0|0|U|0|0^^$0|@$1|2|3|4|5|6|7|1Q|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|1R|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|1S|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|1T|8|@]|9|@]|A|$]]|$1|H|3|I|5|E|7|1U|8|@]|9|@]|A|$]]|$1|J|3|K|5|E|7|1V|8|@]|9|@]|A|$]]|$1|L|3|M|5|E|7|1W|8|@]|9|@]|A|$]]|$1|N|3|O|5|E|7|1X|8|@]|9|@]|A|$]]|$1|P|3|Q|5|E|7|1Y|8|@]|9|@]|A|$]]|$1|R|3|-4|5|6|7|1Z|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|20|8|@]|9|@]|A|$]]|$1|U|3|V|5|E|7|21|8|@]|9|@]|A|$]]|$1|W|3|X|5|6|7|22|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|E|7|23|8|@]|9|@]|A|$]]|$1|10|3|-4|5|6|7|24|8|@]|9|@]|A|$]]|$1|11|3|12|5|6|7|25|8|@]|9|@]|A|$]]|$1|13|3|14|5|6|7|26|8|@]|9|@]|A|$]]|$1|15|3|16|5|6|7|27|8|@]|9|@]|A|$]]|$1|17|3|18|5|6|7|28|8|@]|9|@]|A|$]]|$1|19|3|1A|5|6|7|29|8|@]|9|@]|A|$]]|$1|1B|3|1C|5|6|7|2A|8|@]|9|@]|A|$]]|$1|1D|3|1E|5|6|7|2B|8|@]|9|@]|A|$]]|$1|1F|3|1G|5|6|7|2C|8|@]|9|@$1H|2D|1I|2E|1|2F]]|A|$]]|$1|1J|3|-4|5|6|7|2G|8|@]|9|@]|A|$]]]|1K|$1L|$5|1M|1N|1O|A|$1P|1G]]]]

I deploy mostly ASP.NET apps to Linux servers and redeploy everything for even the smallest change. Here is my standard workflow:

<ul>
<li>I use a source code repository (like Subversion)</li>
<li>On the server, I have a bash script that does the following:

<ul>
<li>Checks out the latest code</li>
<li>Does a build (creates the DLLs)</li>
<li>Filters the files down to the essentials (removes code files for example)</li>
<li>Backs up the database</li>
<li>Deploys the files to the web server in a directory named with the current date</li>
<li>Updates the database if a new schema is included in the deployment</li>
<li>Makes the new installation the default one so it will be served with the next hit</li>
</ul></li>
</ul>

Checkout is done with the command-line version of Subversion and building is done with xbuild (msbuild work-alike from the Mono project). Most of the magic is done in ReleaseIt.

On my dev server I essentially have continuous integration but on the production side I actually SSH into the server and initiate the deployment manually by running the script. My script is cleverly called 'deploy' so that is what I type at the bash prompt. I am very creative. Not.

In production, I have to type 'deploy' twice: once to check-out, build, and deploy to a dated directory and once to make that directory the default instance. Since the directories are dated, I can revert to any previous deployment simply by typing 'deploy' from within the relevant directory.

Initial deployment takes a couple of minutes and reversion to a prior version takes a few seconds.

It has been a nice solution for me and relies only on the three command-line utilities (svn, xbuild, and releaseit), the DB client, SSH, and Bash.

I really need to update the copy of ReleaseIt on CodePlex sometime:

<a href="http://releaseit.codeplex.com/" rel="noreferrer">http://releaseit.codeplex.com/</a>

blocks|key|335832|text|是我为.net应用程序编写的类似capistrano的部署解决方案。这是我们在所有项目中使用的，它是一个非常灵活的解决方案。它解决了Rob+Conery在this+blog+post中解释的.net应用程序的大多数典型问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|335833|335834|它有一个很好的“默认”行为，从某种意义上说，它为你做了很多标准的事情:从源代码管理中获取代码、构建、创建应用程序池、设置IIS等基于powershell源代码的|unordered-list-item|335835|版本具有任务挂钩，因此可以很容易地扩展或更改默认行为dependencies|style|BOLD|335836|it+|335837|<|335838|E118>powershell<代码>E219，因此没有任何外部dependencies|335839|it使用powershell+remoting来访问远程计算机<代码>H222<代码>F223|335840|335841|335842|这里有一个introduction和其他一些博客文章。|335843|因此，为了回答上面的问题：|335844|335845|应用程序是如何打包的(ZIP、MSI等)？|335846|335847|Git+(或其他scm)是在目标计算机上获取应用程序的默认方式。或者，您可以执行本地构建，并将结果复制到Powereshell+connection|335848|When上。第一次部署应用程序时，如何设置应用程序池和虚拟目录(是手动创建还是使用工具创建)？|335849|335850|展开使用Powershell的WebAdministration模块配置应用程序池和网站应用程序。它允许我们(和您)在静态资源更改(CSS、JS或图像文件)时修改应用程序池或网站|335851|的任何方面。您是重新部署整个应用程序，还是仅重新部署修改后的资源？当程序集/ASPX页面改变时怎么办？|335852|335853|是的，展开这样做，任何部署都安装在其他部署的旁边。这样，当出现问题时，我们可以很容易地回滚。它还允许我们轻松地将已部署的版本追溯到源代码管理修订版。|335854|您是否跟踪给定应用程序的所有已部署版本？|335855|335856|是的，unfold保留了旧版本。不是所有版本，而是许多版本。这使得回滚变得几乎微不足道。|335857|entityMap|0|LINK|mutability|MUTABLE|url|http://wekeroad.com/2011/04/05/aspnet-deployment-needs-to-be-fixed|1|http://thomasvm.github.com/blog/2012/10/02/introducing-unfold/^0|25|E|0|0|0|0|4|Y|0|0|3|1|0|1|1|0|18|1|0|1B|1|0|0|0|R|5|C|1|0|0|D|0|0|0|L|0|0|0|22|0|0|1B|0|0|0|2H|0|0|1F|0|0|0|22|0|0|K|0|0|0|18|0^^$0|@$1|2|3|4|5|6|7|1U|8|@]|9|@$A|1V|B|1W|1|1X]]|C|$]]|$1|D|3|-4|5|6|7|1Y|8|@]|9|@]|C|$]]|$1|E|3|F|5|G|7|1Z|8|@]|9|@]|C|$]]|$1|H|3|I|5|G|7|20|8|@$A|21|B|22|J|K]]|9|@]|C|$]]|$1|L|3|M|5|G|7|23|8|@$A|24|B|25|J|K]]|9|@]|C|$]]|$1|N|3|O|5|G|7|26|8|@$A|27|B|28|J|K]]|9|@]|C|$]]|$1|P|3|Q|5|6|7|29|8|@$A|2A|B|2B|J|K]]|9|@]|C|$]]|$1|R|3|S|5|G|7|2C|8|@$A|2D|B|2E|J|K]]|9|@]|C|$]]|$1|T|3|-4|5|6|7|2F|8|@]|9|@]|C|$]]|$1|U|3|-4|5|6|7|2G|8|@]|9|@]|C|$]]|$1|V|3|W|5|6|7|2H|8|@$A|2I|B|2J|J|K]]|9|@$A|2K|B|2L|1|2M]]|C|$]]|$1|X|3|Y|5|6|7|2N|8|@$A|2O|B|2P|J|K]]|9|@]|C|$]]|$1|Z|3|-4|5|6|7|2Q|8|@]|9|@]|C|$]]|$1|10|3|11|5|G|7|2R|8|@$A|2S|B|2T|J|K]]|9|@]|C|$]]|$1|12|3|-4|5|6|7|2U|8|@]|9|@]|C|$]]|$1|13|3|14|5|6|7|2V|8|@$A|2W|B|2X|J|K]]|9|@]|C|$]]|$1|15|3|16|5|G|7|2Y|8|@$A|2Z|B|30|J|K]]|9|@]|C|$]]|$1|17|3|-4|5|6|7|31|8|@]|9|@]|C|$]]|$1|18|3|19|5|6|7|32|8|@$A|33|B|34|J|K]]|9|@]|C|$]]|$1|1A|3|1B|5|G|7|35|8|@$A|36|B|37|J|K]]|9|@]|C|$]]|$1|1C|3|-4|5|6|7|38|8|@]|9|@]|C|$]]|$1|1D|3|1E|5|6|7|39|8|@$A|3A|B|3B|J|K]]|9|@]|C|$]]|$1|1F|3|1G|5|G|7|3C|8|@$A|3D|B|3E|J|K]]|9|@]|C|$]]|$1|1H|3|-4|5|6|7|3F|8|@]|9|@]|C|$]]|$1|1I|3|1J|5|6|7|3G|8|@$A|3H|B|3I|J|K]]|9|@]|C|$]]|$1|1K|3|-4|5|6|7|3J|8|@]|9|@]|C|$]]]|1L|$1M|$5|1N|1O|1P|C|$1Q|1R]]|1S|$5|1N|1O|1P|C|$1Q|1T]]]]

<a href="https://github.com/thomasvm/unfold" rel="nofollow">Unfold</a> is a capistrano-like deployment solution I wrote for .net applications. It is what we use on all of our projects and it's a very flexible solution. It solves most of the typical problems for .net applications as explained in <a href="http://wekeroad.com/2011/04/05/aspnet-deployment-needs-to-be-fixed" rel="nofollow">this blog post</a> by Rob Conery.

<ul>
<li>it comes with a good "default" behavior, in the sense that it does a lot of standard stuff for you: getting the code from source control, building, creating the application pool, setting up IIS, etc</li>
<li>releases based on what's in source control</li>
<li>it has task hooks, so the default behaviour can be easily extended or altered</li>
<li>it has rollback</li>
<li>it's all powershell, so there aren't any external dependencies</li>
<li>it uses powershell remoting to access remote machines</li>
</ul>

Here's an <a href="http://thomasvm.github.com/blog/2012/10/02/introducing-unfold/" rel="nofollow">introduction</a> and some other blog posts.

So to answer the questions above:

<ul>
<li>How is the application packaged (ZIP, MSI, ...)?

Git (or another scm) is the default way to get the application on the target machine. Alternatively you can perform a local build and copy the result over the Powereshell remoting connection</li>
<li>When an application is deployed for the first time how do you setup the App Pool and Virtual Directory (do you create them manually or with some tool)?

Unfold configures the application pool and website application using Powershell's WebAdministration Module. It allows us (and you) to modify any aspect of the application pool or website</li>
<li>When a static resource changes (CSS, JS or image file) do you redeploy the whole application or only the modified resource? How about when an assembly/ASPX page changes?

Yes unfold does this, any deploy is installed next to the others. That way we can easily rollback
when somehting goes wrong. It also allows us to easily trace back a deployed version to
a source control revision.</li>
<li>Do you keep track of all deployed versions for a given application?

Yes, unfold keeps old versions around. Not all versions, but a number of versions. It makes rolling back almost trivial.</li>
</ul>

blocks|key|336882|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|336883|你是在使用一些特定的工具，还是只使用XCOPY？应用程序是如何打包的(ZIP、MSI等)？|blockquote|336884|336885|336886|作为一名BuildMaster开发人员，这自然是我所使用的。所有应用程序都是作为工件在工具中构建和打包的，这些工件在内部存储为ZIP文件。|offset|length|336887|336888|第一次部署应用程序时，如何设置应用程序池和虚拟目录(是手动创建还是使用工具创建)？|336889|336890|336891|手动-我们在工具中创建了一个更改控件，当应用程序在其测试环境中移动时，该控件会提醒我们在未来环境中执行的确切步骤。这也可以通过一个简单的PowerShell脚本实现自动化，但我们不经常添加新的应用程序，所以花1分钟的时间手动创建站点也很容易。|336892|336893|当静态资源(CSS、JS或图像文件)发生变化时，您是重新部署整个应用程序，还是仅重新部署修改后的资源？当程序集/ASPX页面改变时怎么办？|336894|336895|336896|默认情况下，部署工件的过程设置为只将修改过的文件传输到目标服务器-这包括来自CSS文件、JavaScript文件、ASPX页面和链接程序集的所有内容。|336897|336898|您是否跟踪给定应用程序的所有已部署版本，如果出现问题，您是否有将应用程序恢复到先前已知工作状态的过程？|336899|336900|336901|是的，BuildMaster为我们处理了所有这些事情。恢复很大程度上与重新执行旧的构建升级一样简单，但有时需要手动恢复数据库更改，并可能发生数据丢失。基本的回滚过程详述如下：http://inedo.com/support/tutorials/performing-a-deployment-rollback-with-buildmaster|336902|entityMap|0|LINK|mutability|MUTABLE|url|http://inedo.com/buildmaster|1|http://inedo.com/support/tutorials/performing-a-deployment-rollback-with-buildmaster^0|0|0|0|0|4|B|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|2F|2C|1|0^^$0|@$1|2|3|-4|4|5|6|1E|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|1F|7|@]|8|@]|9|$]]|$1|D|3|-4|4|5|6|1G|7|@]|8|@]|9|$]]|$1|E|3|-4|4|5|6|1H|7|@]|8|@]|9|$]]|$1|F|3|G|4|5|6|1I|7|@]|8|@$H|1J|I|1K|1|1L]]|9|$]]|$1|J|3|-4|4|5|6|1M|7|@]|8|@]|9|$]]|$1|K|3|L|4|C|6|1N|7|@]|8|@]|9|$]]|$1|M|3|-4|4|5|6|1O|7|@]|8|@]|9|$]]|$1|N|3|-4|4|5|6|1P|7|@]|8|@]|9|$]]|$1|O|3|P|4|5|6|1Q|7|@]|8|@]|9|$]]|$1|Q|3|-4|4|5|6|1R|7|@]|8|@]|9|$]]|$1|R|3|S|4|C|6|1S|7|@]|8|@]|9|$]]|$1|T|3|-4|4|5|6|1T|7|@]|8|@]|9|$]]|$1|U|3|-4|4|5|6|1U|7|@]|8|@]|9|$]]|$1|V|3|W|4|5|6|1V|7|@]|8|@]|9|$]]|$1|X|3|-4|4|5|6|1W|7|@]|8|@]|9|$]]|$1|Y|3|Z|4|C|6|1X|7|@]|8|@]|9|$]]|$1|10|3|-4|4|5|6|1Y|7|@]|8|@]|9|$]]|$1|11|3|-4|4|5|6|1Z|7|@]|8|@]|9|$]]|$1|12|3|13|4|5|6|20|7|@]|8|@$H|21|I|22|1|23]]|9|$]]|$1|14|3|-4|4|5|6|24|7|@]|8|@]|9|$]]]|15|$16|$4|17|18|19|9|$1A|1B]]|1C|$4|17|18|19|9|$1A|1D]]]]

<blockquote>
 Are you using some specific tools or just XCOPY? How is the application packaged (ZIP, MSI, ...)?
</blockquote>

As a developer for <a href="http://inedo.com/buildmaster" rel="nofollow">BuildMaster</a>, this is naturally what I use. All applications are built and packaged within the tool as artifacts, which are stored internally as ZIP files.

<blockquote>
 When an application is deployed for the first time how do you setup the App Pool and Virtual Directory (do you create them manually or with some tool)?
</blockquote>

Manually - we create a change control within the tool that reminds us the exact steps to perform in future environments as the application moves through its testing environments. This could also be automated with a simple PowerShell script, but we do not add new applications very often so it's just as easy to spend the 1 minute it takes to create the site manually.

<blockquote>
 When a static resource changes (CSS, JS or image file) do you redeploy the whole application or only the modified resource? How about when an assembly/ASPX page changes?
</blockquote>

By default, the process of deploying artifacts is set-up such that only files that are modified are transferred to the target server - this includes everything from CSS files, JavaScript files, ASPX pages, and linked assemblies.

<blockquote>
 Do you keep track of all deployed versions for a given application and in case something goes wrong do you have procedures of restoring the application to a previous known working state?
</blockquote>

Yes, BuildMaster handles all of this for us. Restoring is mostly as simple as re-executing an old build promotion, but sometimes database changes need to be manually restored, and data loss can occur. The basic rollback process is detailed here: <a href="http://inedo.com/support/tutorials/performing-a-deployment-rollback-with-buildmaster" rel="nofollow">http://inedo.com/support/tutorials/performing-a-deployment-rollback-with-buildmaster</a>

blocks|key|335884|text|在我工作的上一家公司，我们使用rSync批处理文件进行部署，只上传自上次上传以来的更改。rSync的美妙之处在于，您可以添加排除列表来排除特定文件或文件名模式。例如，排除我们所有的.cs文件、解决方案和项目文件非常容易。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|335885|我们使用TortoiseSVN进行版本控制，所以能够编写几个SVN命令来完成以下操作是很好的：|335886|335887|首先，检查用户是否有最新版本。|unordered-list-item|335888|从服务器上下载一个名为"synclog.txt“的文本文件，其中详细说明了谁是SVN用户、他们正在上传的修订号以及上传的日期和时间。为当前上传追加一个新行，然后将其与更改后的文件一起发送回服务器。这使得在上传导致问题的可能性很小的情况下，很容易找到要回滚到站点的哪个版本。|335889|335890|除此之外，还有第二个批处理文件，它只检查实时服务器上的文件差异。这可能会突出显示一些人上传但不将其更改提交到SVN的常见问题。结合上面提到的同步日志，我们可以找出谁是可能的罪魁祸首，并要求他们提交他们的工作。|335891|最后，rSync允许您对上传过程中替换的文件进行备份。我们让它将它们移动到一个备份文件夹中，所以如果你突然意识到一些文件不应该被覆盖，你可以找到该文件夹中每个文件的最后备份版本。|335892|虽然这个解决方案在当时感觉有点笨拙，但当我在上传方法不那么优雅或简单的环境中工作时(例如，远程桌面，复制和粘贴整个网站)，我会更欣赏它。|335893|entityMap^0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|T|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|U|8|@]|9|@]|A|$]]|$1|E|3|F|5|G|7|V|8|@]|9|@]|A|$]]|$1|H|3|I|5|G|7|W|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|X|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|Y|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|Z|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|10|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|11|8|@]|9|@]|A|$]]]|R|$]]

At the last company I worked for we used to deploy using an rSync batch file to upload only the changes since the last upload. The beauty of rSync is that you can add exclude lists to exclude specific files or filename patterns. So excluding all of our .cs files, solution and project files is really easy, for instance.

We were using TortoiseSVN for version control, and so it was nice to be able to write in several SVN commands to accomplish the following:

<ul>
<li>First off, check the user has the latest revision. If not, either prompt them to update or run the update right there and then.</li>
<li>Download a text file from the server called "synclog.txt" that details who the SVN user is, what revision number they are uploading and the date and time of the upload. Append a new line for the current upload and then send it back to the server along with the changed files. This makes it extremely easy to find out what version of the site to roll back to on the off chance that an upload causes problems.</li>
</ul>

In addition to this there is a second batch file that just checks for file differences on the live server. This can highlight the common problem where someone would upload but not commit their changes to SVN. Combined with the sync log mentioned above we could find out who the likely culprit was and ask them to commit their work.

And lastly, rSync allows you to take a backup of the files that were replaced during the upload. We had it move them into a backup folder So if you suddenly realised that some of the files should not have been overwritten, you can find the last backup up version of every file in that folder.

While the solution felt a little clunky at the time I have since come to appreciate it a whole lot more when working in environments where the upload method is a lot less elegant or easy (remote desktop, copy and paste the entire site, for instance).

blocks|key|3314410|text|在过去的一年里，我们一直在改进我们的发布过程，现在我们已经把它做好了。我使用Jenkins来管理我们所有的自动化构建和发布，但我相信您可以使用TeamCity或CruiseControl。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3314411|因此，在签入时，我们的“正常”构建将执行以下操作：|3314412|3314413|Jenkins执行SVN更新以获取最新版本的代码|unordered-list-item|3314414|+NuGet包恢复是在我们自己的本地NuGet存储库|3314415|上运行的，应用程序是使用MsBuild编译的。设置这是一个冒险，因为你需要安装正确的MsBuild，然后在你的构建框上安装ASP.NET和MVC。(顺便说一下，当我在我的.csproj文件中输入<MvcBuildViews>true</MvcBuildViews>来编译视图时，msbuild随机崩溃，所以我不得不禁用它)|offset|length|style|CODE|3314416|一旦代码编译完成，单元测试就会运行(我使用了nunit，但你可以使用任何你想要的东西)|3314417|如果所有的单元测试都通过了，我会停止IIS应用程序池，在本地部署应用程序(只需要几个基本的XCOPY命令来复制必要的文件)，然后重启IIS+(我遇到了IIS锁定文件的问题，这解决了它)|3314418|我对每个环境都有单独的web.config文件；dev，uat，prod。(我尝试使用web转换的东西，但收效甚微)。因此，正确的web.config文件也可以跨|3314419|复制，然后我使用PhantomJS执行一系列UI测试。它还会拍摄一系列不同分辨率(手机、桌面)的屏幕截图，并在每个屏幕截图上标记一些信息(页面标题、分辨率)。Jenkins对处理这些屏幕截图提供了很好的支持，一旦集成UI测试通过，这些截图就会保存为build+|3314420|的一部分，即build+is+|3314421|3314422|如果有人点击"Deploy+to+UAT"：|3314423|3314424|如果上一次构建成功，Jenkins将执行另一次SVN更新|3314425|使用RELEASE+configuration|3314426|A+"www“目录编译应用程序，并将应用程序复制到其中|3314427|然后使用winscp在构建框和UAT+|3314428|之间同步文件系统我向UAT服务器发送一个HTTP请求，并确保在SVN中获得200|3314429|<>H130此版本在SVN中标记为UAT-datetime|3314430|If我们到目前为止，构建成功了！<代码>H233<代码>F234|3314431|3314432|单击"Deploy+to+Prod“时：|3314433|3314434|用户选择先前创建的|3314435|标签|3314436|标签会被编译并与Prod服务器|3314437|对Prod服务器|3314438|的Http请求进行同步<代码>H144此修订版本在SVN中标记为压缩并存储<代码>H247<代码>F248|3314439|所有完整的构建到生产大约需要30秒，我对此非常非常满意。|3314440|此解决方案的优点：|3314441|3314442|It's+fast|3314443|单元测试应捕获逻辑错误|3314444|当UI错误进入生产环境时，屏幕截图有望显示导致|3314445|+UAT和Prod保持同步的版本#<|3314446|Jenkins通过所有提交消息向UAT和Prod展示了很棒的发布历史|3314447|UAT和Prod版本都有标签|3314448|3314449|此解决方案的主要缺点是：|3314450|3314451|每当你发布产品的时候，你都需要发布到UAT。这是我们做出的一个有意识的决定，因为我们希望始终确保UAT始终与Prod保持最新。尽管如此，它仍然是一个pain.|3314452|There's，有相当多的配置文件四处漂浮。我试图在Jenkins中实现所有这些功能，但在此过程中需要一些支持批处理文件。(这些也是签入的)。|3314453|DB升级和降级脚本是应用程序的一部分，在应用程序启动时运行。它(大部分)是有效的，但它是一种痛苦。|3314454|3314455|我很乐意听到任何其他可能的改进！|3314456|entityMap^0|0|0|0|0|0|2P|Z|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|2R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|2S|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|2T|8|@]|9|@]|A|$]]|$1|E|3|F|5|G|7|2U|8|@]|9|@]|A|$]]|$1|H|3|I|5|G|7|2V|8|@]|9|@]|A|$]]|$1|J|3|K|5|G|7|2W|8|@$L|2X|M|2Y|N|O]]|9|@]|A|$]]|$1|P|3|Q|5|G|7|2Z|8|@]|9|@]|A|$]]|$1|R|3|S|5|G|7|30|8|@]|9|@]|A|$]]|$1|T|3|U|5|G|7|31|8|@]|9|@]|A|$]]|$1|V|3|W|5|G|7|32|8|@]|9|@]|A|$]]|$1|X|3|Y|5|G|7|33|8|@]|9|@]|A|$]]|$1|Z|3|-4|5|6|7|34|8|@]|9|@]|A|$]]|$1|10|3|11|5|6|7|35|8|@]|9|@]|A|$]]|$1|12|3|-4|5|6|7|36|8|@]|9|@]|A|$]]|$1|13|3|14|5|G|7|37|8|@]|9|@]|A|$]]|$1|15|3|16|5|G|7|38|8|@]|9|@]|A|$]]|$1|17|3|18|5|G|7|39|8|@]|9|@]|A|$]]|$1|19|3|1A|5|G|7|3A|8|@]|9|@]|A|$]]|$1|1B|3|1C|5|G|7|3B|8|@]|9|@]|A|$]]|$1|1D|3|1E|5|6|7|3C|8|@]|9|@]|A|$]]|$1|1F|3|1G|5|G|7|3D|8|@]|9|@]|A|$]]|$1|1H|3|-4|5|6|7|3E|8|@]|9|@]|A|$]]|$1|1I|3|1J|5|6|7|3F|8|@]|9|@]|A|$]]|$1|1K|3|-4|5|6|7|3G|8|@]|9|@]|A|$]]|$1|1L|3|1M|5|G|7|3H|8|@]|9|@]|A|$]]|$1|1N|3|1O|5|G|7|3I|8|@]|9|@]|A|$]]|$1|1P|3|1Q|5|G|7|3J|8|@]|9|@]|A|$]]|$1|1R|3|1S|5|G|7|3K|8|@]|9|@]|A|$]]|$1|1T|3|1U|5|6|7|3L|8|@]|9|@]|A|$]]|$1|1V|3|1W|5|6|7|3M|8|@]|9|@]|A|$]]|$1|1X|3|1Y|5|6|7|3N|8|@]|9|@]|A|$]]|$1|1Z|3|-4|5|6|7|3O|8|@]|9|@]|A|$]]|$1|20|3|21|5|G|7|3P|8|@]|9|@]|A|$]]|$1|22|3|23|5|G|7|3Q|8|@]|9|@]|A|$]]|$1|24|3|25|5|G|7|3R|8|@]|9|@]|A|$]]|$1|26|3|27|5|G|7|3S|8|@]|9|@]|A|$]]|$1|28|3|29|5|G|7|3T|8|@]|9|@]|A|$]]|$1|2A|3|2B|5|G|7|3U|8|@]|9|@]|A|$]]|$1|2C|3|-4|5|6|7|3V|8|@]|9|@]|A|$]]|$1|2D|3|2E|5|6|7|3W|8|@]|9|@]|A|$]]|$1|2F|3|-4|5|6|7|3X|8|@]|9|@]|A|$]]|$1|2G|3|2H|5|G|7|3Y|8|@]|9|@]|A|$]]|$1|2I|3|2J|5|G|7|3Z|8|@]|9|@]|A|$]]|$1|2K|3|2L|5|G|7|40|8|@]|9|@]|A|$]]|$1|2M|3|-4|5|6|7|41|8|@]|9|@]|A|$]]|$1|2N|3|2O|5|6|7|42|8|@]|9|@]|A|$]]|$1|2P|3|-4|5|6|7|43|8|@]|9|@]|A|$]]]|2Q|$]]

We've been improving our release process for the past year and now we've got it down pat. I'm using Jenkins to manage all of our automated builds and releases, but I'm sure you could use TeamCity or CruiseControl.

So upon checkin, our "normal" build does the following:

<ul>
<li>Jenkins does a SVN update to fetch the latest version of the code</li>
<li>A NuGet package restore is done running against our own local NuGet repository</li>
<li>The application is compiled using MsBuild. Setting this up is an adventure, because you need to install the correct MsBuild and then the ASP.NET and MVC dll's on your build box. (As a side note, when I had <code>&lt;MvcBuildViews&gt;true&lt;/MvcBuildViews&gt;</code> entered in my .csproj files to compile the views, msbuild was randomly crashing, so I had to disable it)</li>
<li>Once the code is compiled the unit tests are run (I'm using nunit for this, but you can use anything you want)</li>
<li>If all the unit tests pass, I stop the IIS app pool, deploy the app locally (just a few basic XCOPY commands to copy over the necessary files) and then restart IIS (I've had problems with IIS locking files, and this solved it)</li>
<li>I have separate web.config files for each environment; dev, uat, prod. (I tried using the web transformation stuff with little success). So the right web.config file is also copied across</li>
<li>I then use PhantomJS to execute a bunch of UI tests. It also takes a bunch of screenshots at different resolutions (mobile, desktop) and stamps each screenshot with some information (page title, resolution). Jenkins has great support for handling these screenshots and they are saved as part of the build</li>
<li>Once the integration UI tests pass the build is successful</li>
</ul>

If someone clicks "Deploy to UAT":

<ul>
<li>If the last build was successful, Jenkins does another SVN update</li>
<li>The application is compiled using a RELEASE configuration</li>
<li>A "www" directory is created and the application is copied into it</li>
<li>I then use winscp to synchronise the filesystem between the build box and UAT</li>
<li>I send a HTTP request to the UAT server and make sure I get back a 200</li>
<li>This revision is tagged in SVN as UAT-datetime</li>
<li>If we've got this far, build is successful!</li>
</ul>

When we click "Deploy to Prod":

<ul>
<li>The user selects a UAT Tag that was previously created</li>
<li>The tag is "switched" to</li>
<li>Code is compiled and synced with Prod server</li>
<li>Http request to Prod server</li>
<li>This revision is tagged in SVN as Prod-datetime</li>
<li>The release is zipped and stored</li>
</ul>

All up a full build to production takes about 30 secs which I'm very, very happy with. 

Upsides to this solution:

<ul>
<li>It's fast</li>
<li>Unit tests should catch logic errors</li>
<li>When a UI bug gets into production, the screenshots will hopefully show what revision # caused the it</li>
<li>UAT and Prod are kept in sync</li>
<li>Jenkins shows you a great release history to UAT and Prod with all of the commit messages</li>
<li>UAT and Prod releases are all tagged automatically</li>
<li>You can see when releases happen and who did them </li>
</ul>

The main downsides to this solution are:

<ul>
<li>Whenever you do a release to Prod you need to do a release to UAT. This was a conscious decision we made because we wanted to always ensure that UAT is always up to date with Prod. Still, it's a pain.</li>
<li>There's quite a few configuration files floating around. I've attempted to have it all in Jenkins, but there's a few support batch files needed as part of the process. (These are also checked in).</li>
<li>DB upgrade and downgrade scripts are part of the app and run at app startup. It works (mostly), but it's a pain.</li>
</ul>

I'd love to hear any other possible improvements!

blocks|key|3314491|text|我建议不要只覆盖现有的应用程序文件，而是要为每个版本创建一个目录，并将IIS应用程序重定向到新路径。这有几个好处：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3314492|3314493|根据需要快速恢复|unordered-list-item|3314494|不需要停止IIS或应用程序池以避免锁定问题|3314495|没有旧文件导致问题的风险|3314496|或多或少零停机时间(通常只是在新应用程序域初始化时暂停)|3314497|<代码>F29|3314498|我们遇到的唯一问题是，如果不重新启动应用程序池并依赖自动应用程序域切换，资源将被缓存。|3314499|entityMap^0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|S|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|T|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|U|8|@]|9|@]|A|$]]|$1|H|3|I|5|E|7|V|8|@]|9|@]|A|$]]|$1|J|3|K|5|E|7|W|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|X|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|Y|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|Q|$]]

I'd recommend NOT just overwriting existing application files but instead create a directory per version and repointing the IIS application to the new path.
This has several benefits:

<ul>
<li>Quick to revert if needed</li>
<li>No need to stop IIS or the app pool to avoid locking issues</li>
<li>No risk of old files causing problems</li>
<li>More or less zero downtime (usually just a pause at the new appdomain initialises)</li>
</ul>

The only issue we've had is resources being cached if you don't restart the app pool and rely on the automatic appdomain switch.

I am looking for different techniques/tools you use to deploy an ASP.NET web application project (NOT ASP.NET web site) to production? 

I am particularly interested of the workflow happening between the time your Continuous Integration Build server drops the binaries at some location and the time the first user request hits these binaries.

<ol>
<li>Are you using some specific tools or just XCOPY? How is the application packaged (ZIP, MSI, ...)? </li>
<li>When an application is deployed for the first time how do you setup the App Pool and Virtual Directory (do you create them manually or with some tool)? </li>
<li>When a static resource changes (CSS, JS or image file) do you redeploy the whole application or only the modified resource? How about when an assembly/ASPX page changes?</li>
<li>Do you keep track of all deployed versions for a given application and in case something goes wrong do you have procedures of restoring the application to a previous known working state?</li>
</ol>

Feel free to complete the previous list.

<hr>

And here's what we use to deploy our ASP.NET applications:

<ol>
<li>We add a <a href="http://www.microsoft.com/downloads/details.aspx?FamilyId=0AA30AE8-C73B-4BDD-BB1B-FE697256C459&amp;displaylang=en" rel="noreferrer">Web Deployment Project</a> to the solution and set it up to build the ASP.NET web application</li>
<li>We add a Setup Project (NOT Web Setup Project) to the solution and set it to take the output of the Web Deployment Project</li>
<li>We add a custom install action and in the OnInstall event we run a custom build .NET assembly that creates an App Pool and a Virtual Directory in IIS using <a href="http://msdn.microsoft.com/en-us/library/system.directoryservices.directoryentry.aspx" rel="noreferrer">System.DirectoryServices.DirectoryEntry</a> (This task is performed only the first time an application is deployed). We support multiple Web Sites in IIS, Authentication for Virtual Directories and setting identities for App Pools.</li>
<li>We add a custom task in TFS to build the Setup Project (TFS does not support Setup Projects so we had to use devenv.exe to build the MSI)</li>
<li>The MSI is installed on the live server (if there's a previous version of the MSI it is first uninstalled)</li>
</ol>

How do you deploy your ASP.NET applications to live servers?

单元测试

身份验证

数据丢失

数据中心

文件系统

数据库

服务器

Linux

我正在寻找不同的技术/工具，你用来部署一个ASP.NET web应用程序项目(而不是 ASP.NET网站)到生产？我特别感兴趣的是，从持续集成构建服务器将二进制文件放到某个位置到第一个用户请求命中这些二进制文件这段时间之间发生的工作流。，你是在使用一些特定的工具，还是只使用XCOPY？如何打包应用程序(ZIP、MSI等...

问如何将ASP.NET应用程序部署到实时服务器？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何将ASP.NET应用程序部署到实时服务器？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何将ASP.NET应用程序部署到实时服务器？
EN