在真正开始讨论之前先定义一下 Scope。
最近观看了总共十三季的 Air crash investigation，感到 IT 研发和运维的就像是这些场景的重现。事实上，我们做的许多 IT 系统的复杂程度都接近甚至超过了飞机。因为我们要维护比飞机多得多的内部状态，只不过飞机对稳定性和可靠性的要求比一般 IT 系统要多得多。前人的经验非常值得我们学习。如果你没有那么多时间全部看完，那么请看以下的吐槽（有些案例，例如 法国航空8969号，1994 并未过多涉及行业经验故而略过），挑选自己感兴趣的看一看吧。
前一篇文章请看：空难与 IT 系统的设计和维护 (上)
最近观看了总共十三季的 Air crash investigation，感到 IT 研发和运维的就像是这些场景的重现。事实上，我们做的许多 IT 系统的复杂程度都接近甚至超过了飞机。因为我们要维护比飞机多得多的内部状态，只不过飞机对稳定性和可靠性的要求比一般 IT 系统要多得多。前人的经验非常值得我们学习。如果你没有那么多时间全部看完，那么请看以下的吐槽（有些案例，例如 法国航空8969号，1994 并未过多涉及行业经验故而略过），挑选自己感兴趣的看一看吧。
今天这篇文章是准备瞎扯的。平常工作的时候，我希望尽可能的将一切自动化，让自己尽可能的舒适与懒惰。两个输入设备（键盘+鼠标）太累，我只想用一个，例如我不希望翻箱倒柜的去翻找 GO-Agent 在哪里，我希望用一个命令就可以开启它。我希望用一个脚本就完成整个工程的依赖的下载，构建，打包，部署，然后让 Pipeline 去跑自动化的单元测试和集成测试。总之，好像有命令行就足够了，我不需要GUI。
但是，这是不可能的。即使在工作中 80% 的时间都在敲打键盘，但是其余的事件我都在浏览器上转悠，这需要鼠标（我知道 Chrome 上有类似 Vim 快捷键的东西，但是它是有副作用的，基于这种考虑，我很少在测试环境下使用它）。在其他的一些场景下，我也希望有接口有图形化的表示，例如，查看 git 的分支。还有一个领域，那就是 Coach。
这是这个系列的第五篇了，前四篇请参见：
简单来说，部署就是 “构建（Build）” -> “拷贝（打包）” -> “配置”。在前一篇中，我们介绍了“构建”，那么这一篇就说说拷贝（好像我们更习惯于说打包，那么以后我们就叫它打包吧）的事情。为什么要打包呢？在应用程序发布的时候我们当然只希望发布运行时需要的文件，而其他的文件，例如：工程文件，源代码等等是不需要进行发布的。因此我们需要将运行时所需的文件分离出来，做成一个干净的 Package。
这是这个系列的第四篇了，前三篇请参见：
这一篇中我们会写一些关于自动化部署的代码。我们会使用 Powershell 书写这类代码。我不会向你讲为什么要自动化部署，这种大道理讲的太多了。你将发现这篇文章中涉及的东西非常具体，有的要求甚至相当苛刻且可能不具有通用性。这是因为部署从来都是跟环境打交道，部署过程中协作的组建太多，相互之间的交集不可能太大。可能唯一能够通用的是自动化部署的基本原则（只是这篇文章的基本原则）：