持续集成和部署改变生活的奇迹 (The life-changing wonder of Continuous Integration and Deployment)

In the first year or so of , I used to piece together sites page-by-page. When I was done, I’d FTP the results to my hosting provider via my 56k modem, and would let them do whatever it was that they needed to do to make the site run on the web.

在的第一年左右，我使用逐页地整理了站点。完成后，我会将结果通过我的56k调制解调器FTP发送到托管服务提供商，然后让他们做他们需要做的一切，以使网站在网络上运行。

I didn’t need to know how it worked; it just worked. The files I uploaded wrote directly over the old files. And if I needed to change anything, I just wrote directly over those files too. And if I made a mistake and needed to go back, I just had to hope I’d remembered to back up to that external hard drive fairly recently, or I’d have a late night ahead!

我不需要知道它是如何工作的。它只是工作。我上传的文件直接覆盖了旧文件。如果我需要更改任何内容，我也可以直接在这些文件上写。而且，如果我犯了一个错误并需要返回，我只希望希望我记得最近才备份到该外部硬盘驱动器，否则我可能要深夜了！

Forward three or four years, we were a team of three, co-locating our own server network down in in the London Docklands. Our sites were database-driven using SQL Server 2000, and the HTML was generated by ASP and VBscript. When we upgraded a site, we had to remember the files that we’d changed as part of the release, and upload those files.

前进三到四年，我们是一个由三人组成的团队，将我们自己的服务器网络放置在伦敦港区的中。我们的站点是使用SQL Server 2000由数据库驱动的，而HTML是由ASP和VBscript生成的。升级网站时，我们必须记住在发行版中更改过的文件，并上传这些文件。

After some time we learned to create a new folder for each upgrade, so that we could use that as a staging site, until we were ready to go live — then we’d work with IIS and domain bindings and DNS to make the staging site go live.

一段时间后，我们学会了为每次升级创建一个新文件夹，以便我们可以将其用作登台站点，直到准备上线为止—然后，我们将使用IIS和域绑定以及DNS来制作登台站点上线。

It worked, but it was prone to all sorts of errors. We might forget to change a configuration file during the go-live process. Or something that worked previously would suddenly stop working because of a change we’d made somewhere else in the project, and we hadn’t thought to test that aspect of the site. And if a very quick fix was needed, we would often give in to temptation and simply upload the fix right onto the live site, instead of using a new staging folder.

它可以工作，但是容易出现各种错误。我们可能会忘记在上线过程中更改配置文件。否则以前的工作可能由于我们在项目中其他地方所做的更改而突然停止工作，并且我们并未考虑测试站点的这一方面。而且，如果需要非常快速的修复程序，我们通常会屈服于诱惑，只是将修复程序直接上载到实时站点，而不是使用新的暂存文件夹。

We installed, upgraded and managed the servers ourselves. If a component in the server broke down, it was up to us to fix it.

我们自己安装，升级和管理服务器。如果服务器中的某个组件发生故障，则必须由我们来修复它。

I remember one time, one of our web servers went down — I called up an engineer on site, who became my eyes, opening up the machine, and telling me what he could see. I deduced that the power supply had blown, and proceeded online to search the computer supply stores that were near the data center to find one who had this near-obsolete power supply (the server was our first, and it was getting on a bit). When I found one, I paid a London motorcycle courier to pick up the supply, and drive it to the data center where the engineer was waiting to install it. The sites were all back up again after three very tense hours.

我记得有一次，我们的一台Web服务器发生故障—我打电话给现场的一名工程师，他成为我的眼睛，打开机器，并告诉我他能看到什么。我推断出电源已断电，然后在线搜索位于数据中心附近的计算机耗材商店，以找到拥有这种陈旧电源的人(服务器是我们的第一台，并且正在运行中) 。当我找到一个时，我付钱给伦敦的一家摩托车快递公司取货，然后把它运到工程师正在等待安装的数据中心。在三个非常紧张的小时后，所有站点再次恢复。

Forward another eight or so years, there were five of us in the team and virtual servers have become a viable proposition, and, given the advantages, we dived in. If I needed a new server, I no longer needed to order it, install the software, drive down to London and screw it into the racks myself (although I always felt pretty space-age whenever I worked in the data center). I’d just need to press a few buttons on my console, and 20 minutes later the server would be spun up and ready to roll.

再向前八年左右，团队中有五个人，虚拟服务器已成为可行的方案，并且鉴于优势，我们投入了。如果我需要新服务器，则不再需要订购它，安装软件，开车去伦敦，然后自己把它拧进机架(尽管每次在数据中心工作时，我总是觉得空间很大)。我只需要按一下控制台上的几个按钮，然后20分钟后，服务器便会启动并准备启动。

If I needed more hard drive space, it no longer meant downtime while I took the machine out of its racks and screwed the drive into place, configuring RAID (terrifying) and hoping the whole thing booted up again cleanly. Instead, now I’d just click a few buttons on the online console, do a quick reboot, and the drive would be available to me.

如果我需要更多的硬盘空间，那么当我从机架中取出机器并将驱动器固定到位，配置RAID(令人恐惧)并希望整个设备重新启动时，就不再意味着停机。取而代之的是，现在我只需单击在线控制台上的几个按钮，进行快速重启，即可使用该驱动器。

If a power supply failed, the server instance would simply move itself to another of the multiple blade servers available, and would pop back online again within minutes. It was still a little clunky to operate, and I still needed to manage software updates and stay on top of resources such as CPU, RAM and disk space, but it was a huge improvement.

如果电源出现故障，该服务器实例将简单地将自身移至可用的多个刀片服务器中的另一个，然后在几分钟之内再次弹出联机状态。操作起来仍然有些笨拙，我仍然需要管理软件更新并保持在CPU，RAM和磁盘空间等资源之上，但这是一个巨大的进步。

Our deployment processes didn’t change much during that transition . We became more vigilant about our staging folders. Instead of using folders called ‘dev’, and ‘live’ — which would immediately become confused when we needed a new version (‘dev 2, or ‘new live’, later becoming ‘live final’, live final 2’ etc), we used release-version numbering for the folders instead — ‘v1’, ‘v1.5’, ‘v2’ etc. The process was more robust, along with our growing knowledge of how to avoid the common pitfalls to keep our sites live and error free, but human error was still possible, and doing small updates was still a fairly major operation if we were to do it properly without the error-prone shortcuts.

在此过渡期间，我们的部署过程没有太大变化。我们对暂存文件夹变得更加警惕。而不是使用名为“ dev”和“ live”的文件夹-当我们需要新版本(“ dev 2”或“ new live”，后来变成“ live final”，live final 2等)时，它们会立即变得混乱，我们使用了发行版编号编号的文件夹-“ v1”，“ v1.5”，“ v2”等。此过程更加健壮，并且我们对如何避免常见陷阱以保持站点正常运行的认识不断增长。没有错误，但是仍然可能发生人为错误，并且如果我们不使用容易出错的快捷方式正确地进行操作，则进行小的更新仍然是一项相当大的操作。

As we moved into more enterprise-level applications and mobile apps, our deployment processes became more sophisticated. Online applications required multiple configuration files, and mobile apps had many stages of build and deployment, with batch files, server scripts, and all sorts of manual configuration to get to the finished product. A lot of the knowledge that we needed for these processes was kept in the heads of the developers who needed it, and the concern with that is if those developers moved on, so could that knowledge.

随着我们转向更多企业级应用程序和移动应用程序，我们的部署过程变得越来越复杂。在线应用程序需要多个配置文件，而移动应用程序则具有构建和部署的多个阶段，包括批处理文件，服务器脚本和各种手动配置，以完成产品。我们需要这些流程的很多知识都掌握在需要它的开发人员的脑海中，而与此相关的问题是，如果这些开发人员继续前进，那么这些知识也就可以了。

But technology evolves at a dizzying pace, and at Remote we love to keep up with that pace.

但是技术的发展令人眼花pace乱，在Remote，我们喜欢与时俱进。

Fast forward to 2017, now an Agile team of developers, designers and project managers, the company is unrecognizable from it’s humble beginnings and the Cloud is all. We’ve moved most of our applications over to — the flexibility of the App Service is astonishing. We can fire up a new service, tell it whether it’s .NET, .NET Core, PHP, or whichever flavor of code we’re working with, and set up the usual things we’d set up in IIS, but in a simple form.

快进到2017年，现在是一个由开发人员，设计师和项目经理组成的敏捷团队，该公司从一开始就不起眼，而云就是一切。我们已将大多数应用程序移至 -应用程序服务的灵活性令人惊讶。我们可以启动一个新服务，告诉它是.NET，.NET Core，PHP还是我们正在使用的任何形式的代码，并以简单的方式设置我们将在IIS中设置的常规功能。形成。

We can add the an application to the service plan, where all apps share the allocated memory, CPU and so on, giving back the resources to the pool when they’re not needed. The Service connects with Azure SQL, which behaves in a similar way, sharing resources with its pool, and reducing resources when they’re not needed. A customizable dashboard provides graphs of resource utilization over all the applications and services, and we can isolate a service and move it into its own resource pool in a couple of clicks, with no downtime.

我们可以将一个应用程序添加到服务计划中，其中所有应用程序共享分配的内存，CPU等，并在不需要它们时将资源返回给池。该服务与Azure SQL连接，Azure SQL的行为类似，与池共享资源，并在不需要时减少资源。可定制的仪表板提供了所有应用程序和服务的资源利用率图表，我们只需单击几下即可隔离服务并将其移动到其自己的资源池中，而无需停机。

If an application finds itself under heavier-than-usual demand, Azure can ‘Scale-out’, and create a new, copied instance of the application in real-time, sharing visitor traffic between the two, three, four, or ten copies of the application as needed — when the demand drops again, so do the copied instances. All while I sleep.

如果应用程序的需求超出正常水平，Azure可以“横向扩展”并实时创建该应用程序的新复制实例，从而在两个，三个，四个或十个副本之间共享访问者流量应用程序的需求-当需求再次下降时，复制的实例也是如此。我一直在睡觉。

All of our version control is managed with Git. No more scrabbling through backups to find a previous version of a file. We just roll our version of the source code back to a time when the file was in place, and make whatever changes necessary. New changes are merged smoothly and easily with the ‘master’ trunk, often following a ‘pull request’, where peers can review and comment on new sections of code before they’re allowed to join the main source. And when that code is committed to the master, oh sweet delight…

我们所有的版本控制都通过Git进行管理。无需再花时间检查备份以查找文件的先前版本。我们只是将源代码的版本回滚到文件就位的时间，并进行必要的更改。新更改可以轻松地与“主”主干轻松合并，通常是在“拉取请求”之后进行的，在“主请求”主干中，同级可以先查看和评论新的代码部分，然后再加入主要源代码。当该代码提交给主服务器时，噢，甜蜜的喜悦……

Continuous Integration and Deployment is to me the most exciting development of all in recent years. I commit my code to the master trunk, and VSTS recognises that the code has been changed. Immediately, it runs my task list — it takes the full code, downloads any relevant packages, builds the solution, runs our unit tests to make sure that everything still does what it should, and then once all is well, it publishes the whole project to a staging folder and warms it up so that when we visit the site for the first time, we don’t have to wait for it to load up. Once we’ve given the staging site a series of QA manual tests to be sure that we’re happy with it, a single mouse click swaps the staging and production slots, making our new updates go live without any downtime at all for the website visitor. And the previous production version is now held in staging, just in case we have need to quickly roll back again.

对我来说，持续集成和部署是近年来最激动人心的发展。我将代码提交到主干，而VSTS识别出代码已更改。立即，它运行我的任务列表-获取完整的代码，下载任何相关的程序包，构建解决方案，运行我们的单元测试，以确保一切仍按预期进行，然后一切顺利，就发布了整个将项目投影到暂存文件夹中并对其进行预热，这样，当我们第一次访问该站点时，我们不必等待它加载。一旦我们对暂存站点进行了一系列的质量检查手动测试以确保对此感到满意，那么只需单击一下鼠标即可交换暂存和生产位置，从而使我们的新更新可以在不停机的情况下上线游客。以前的生产版本现在处于暂存状态，以防万一我们需要快速回滚。

It’s brilliant, it’s simple, it removes many, many possibilities for human error, and it’s so much faster. And with more complicated builds, these scripts and batch files can be programmed into the deployment — no more checklists and things to remember, just a Git check-in, and the project is deployed. We have finely detailed control on how the build happens, and what happens during that build, and the order of tasks can be altered as we desire. It feels like we’ve reached a kind of technological utopia.

它出色，简单，消除了很多人为错误的可能性，而且速度更快。通过更复杂的构建，可以将这些脚本和批处理文件编程到部署中-不再需要清单和要记住的东西，只需Git签入，就可以部署项目。我们对构建如何进行以及在构建期间发生了什么以及任务的顺序进行了非常详细的控制，我们可以根据需要进行更改。感觉我们已经达到了某种技术上的乌托邦。

Of course, the setup isn’t always completely straightforward and out-of-the-box . An online application that uses Session ID’s for example, will need to be re-coded to use something like the Azure Redis Cache to hold those states, so that they’re accessible from multiple instances, and not lost when an App Service switches servers.

当然，设置并不总是完全简单明了的。例如，使用会话ID的在线应用程序将需要重新编码，以使用诸如Azure Redis缓存之类的东西来保存这些状态，以便可以从多个实例访问它们，并且在App Service切换服务器时不会丢失。

In Azure, everything is volatile and a site which holds user files such as images or documents needs to be reprogrammed to hold those files on shared virtual storage drives, so that when the CD swaps deployment slots, the latest files aren’t swapped too. But, it’s easy to do and the benefits are immense.

在Azure中，一切都是易变的，并且包含用户文件(例如图像或文档)的网站需要重新编程，以将这些文件保存在共享的虚拟存储驱动器上，以便在CD交换部署插槽时，也不会交换最新文件。但是，这很容易做到，而且好处是巨大的。

Staying within the Microsoft Stack for the entire development cycle has huge benefits too — We develop using , and host our Git repositories on , which is where we’ve migrated our project management process to as well, so that we can work on an issue, relate Git commits to it, and see which build the issue was released in, all within the same software. Pull requests mean that other developers can review and comment on the code from within Visual Studio, which can also manage the Git pulls and commits. We can set up CI/CD in Azure and then make more granular changes to that setup within VSTS, all very quickly and transparently.

在整个开发周期中使用Microsoft Stack也具有巨大的好处-我们使用开发，并将Git存储库托管在，这也是我们将项目管理流程迁移到的地方，以便我们可以继续进行问题，将Git提交给它，并查看问题发布在哪个内部版本中，所有这些都在同一软件内。提取请求意味着其他开发人员可以在Visual Studio中查看和评论代码，这也可以管理Git的提取和提交。我们可以在Azure中设置CI / CD，然后非常快速，透明地对VSTS中的设置进行更精细的更改。

I can even get a message when a build is completed, or, more importantly maybe, when it fails; we create a new Git branch for each issue we work on, and then commit that branch back to the trunk, so we get immediate feedback from the CI system if something has broken, and immediate feedback from the client, who can access the staging site — no more waiting two weeks for an official release, when we would then have to merge all of our development branches into the master at once — sheer hell — instead, a steady, gradual and safe deployment. The ability for clients to give such instant feedback means that they can see what element of a project we’re working on and give early feedback, so that we can implement any adjustments early in the life-cycle.

当构建完成，或者更重要的是，当构建失败时，我什至可以收到一条消息。我们为所处理的每个问题创建一个新的Git分支，然后将该分支提交回主干，因此，如果发生问题，我们会立即从CI系统获得反馈，并从可以访问登台站点的客户端获得立即反馈。 —不再需要等待两周的正式发布时间，那时我们将不得不将所有开发分支立即合并到主服务器中—真是地狱—而是稳定，逐步和安全的部署。客户提供即时反馈的能力意味着他们可以看到我们正在研究的项目的哪个元素并提供早期反馈，以便我们可以在生命周期的早期进行任何调整。

It really feels like we’re at the point where this kind of automation provides a juicy layer of immediacy, interaction and intelligence that has always been needed in managing these processes, and the result is a huge improvement in reliability and speed and quality. I’ll go more deeply into the details of all these technologies in future articles, but for now, here’s to the brave new world; I’m a very happy resident.

确实感觉到我们处在这种自动化提供了多汁的即时性，交互性和智能性层的水平，这在管理这些过程中始终是必需的，其结果是可靠性，速度和质量得到了极大的提高。在以后的文章中，我将更深入地介绍所有这些技术的细节，但是现在，这是一个勇敢的新世界。我是一个非常幸福的居民。

Originally published at .

最初发布在。