软体上线流程中有哪些阶段?

除了写程式外，软体工程师在完成程式后，也需要将程式部署。在这篇文章中，我们将会完整走过软体开发的上线流程，让身为软体工程师的你，能确保把关好团队的上线流程。

在完成开发之后，多数软体开发团队会有以下的上线流程 (备注：多数团队不会走过下面提的所有流程，所以实际要跑哪些流程，还是以你所在的团队的规范为主)

开发

在完成技术设计后，团队会进到开发阶段，这时会在开发环境 (Development Environment) 进行。多半这时会是在本地进行，不过近年来许多云端 IDE 越做越好，也逐渐有在云端环境进行开发。

内部测试

在完成开发后，会先在内部进行测试，这时会进到内部测试环境。内部测试一般会分成两种，一个是 Alpha 测试，另一个是狗粮测试 (dogfooding)。

1. Alpha 测试 所谓的 Alpha 测试，是在开发完后，由开发者自己测试，或是请团队中的 QA 来协助测试。Alpha 测试的目的，是要确保要上线的功能都如预期，同时既有的功能没有被影响，借此来确保软体的稳定性。测试过程通常会涵盖所有的功能，模拟使用者操作软体的行为，来确保功能都没有问题。

2. 狗粮测试 (dogfooding) 在 Alpha 测试后，接着会进到狗粮测试。所谓狗粮测试是指让内部员工自己使用，自己从使用者的角度来试产品，借此来搜集问题。举例来说，在 《Threads 团队如何开发这款史上最快达成一亿注册的产品》一文中，我们谈到，Threads 团队在产品开发更趋于完整后，开给整个 Instagram 团队来做狗粮测试，并从其他人的使用过程中搜集回报的问题。 之所以叫狗粮测试，是出自于多年前微软的 Paul Maritz 寄送一封给软体测试主管的信件中提到 Eating our own Dogfood (吃我们自己的狗粮)，借此来比喻自己开发的产品，自家员工要自己用过。

   这种把自己当使用者来测试的方法，不仅能帮忙抓出许多问题，也能从中获得一些对产品的洞见。因为这个做法非常有效，吃自己的狗粮逐渐演化成一个业界常态的做法，时至今日被称为狗粮测试 (dogfooding)。

模拟环境测试

由于在内部测试时，各种环境变数或设定，不必然跟真实线上环境相同。许多时候这样做是为了做隔离，确保在测试环境做测试时，不会影响到线上的环境。因此，在测试环境的测试都完成后，会进一步到模拟环境 (Staging Environment) 做测试。模拟环境顾名思义是在模拟正式的生产环境，确保各面向都没问题，不会因为不同的环境变数、依赖等因素改变，导致软体无法如预期运行。

Beta 测试

在模拟环境测试完成后，接着会进到 Beta 测试。Beta 测试有两种，一种是封闭的 Closed Beta，就是大家常听到的封测；另一种是公开的 Open Beta，就是大家常听到的公测。不论是哪一种，在 Beta 测试时，不仅是环境会模拟正式环境，还会真的邀请外部使用者来。

虽然仅会邀请少数使用者，Beta 测试仍很有价值，因为通常在有外部使用者参与测试，能协助系统找到更多潜在的问题 (毕竟许多时候，使用者在用产品时，可能会有各种让人意想不到的方式)，同时也能给予产品回馈，协助产品迭代。

金丝雀 (canary) 部署

在前面的各种测试阶段都完成后，接着就要正式将软体部署上线。而在部署上生产环境时，一般来说会分阶段上线，而不是一次全上，例如 10% 后 30% 然后 50%，最后 100%。会这么做是因为从小流量开始上线，能够确保如果真的不小心出问题，只会影响到新上线的部分。例如在 10% 流量时，就发现问题，那这样影响的范围只会是那 10%。这种分小流量来避免出问题时影响过大，是金丝雀部署的优点之一。

你可能会好奇，为什么要叫金丝雀部署? 这个命名是源自早年矿场为了确保矿坑没有毒气，在矿工实际进入矿坑前，会先放金丝雀去探勘，假如金丝雀能顺利飞回来，代表矿坑没有毒气；反之，如果金丝雀没有飞回来，那估计因为矿坑中的毒气导致金丝雀死亡，这时矿工团队就知道不该继续往下挖矿。

而对应到程式码的部署，金丝雀部署就像放出金丝雀，先以金丝雀去探勘，而不是直接全量上线，这样遇到问题的话，也只有前面有被放出的小流量会被影响，而不会造成过于巨大的损失。在早期许多团队也会用一种叫蓝绿部署的方式，也是先有测试后，直接把所有流量都切到最新的版本。然而这种方式的灵活性相对低，因此目前业界更偏向金丝雀部署。

A/B 测试

现代软体团队，在做小流量的部署时，多半会搭配 A/B 测试来进行。Spotify 团队先前分享，他们使用的流程，会是用功能切换 (feature toggle) 的形式进行 (详见此文)。一开始只切换开给有特定标示的使用者可以用到新功能，例如在内部测试阶段，新功能的流量只会打到带有内部人员标示的使用者。

接着再逐步放量，例如 20% 的流量的使用者会进到新功能的流量。而这 20% 会是以随机的方式，确保能够同时来跑 A/B 测试，如果实验的结果有符合预期 (例如新功能带来更好的效果)，在 A/B 测试时会逐步放量直到 100%；反之，如果新功能不符预期，在实验阶段就会先终结，不继续做全量的放量。

全量上线

在走过上面的完整流程后，新的产品或功能就到全量上线的阶段。然而这阶段不代表结束，因为全量上线后，仍要保持对产品与系统的监控，以确保发生问题时，能够即时响应并解决。

与此同时，要确保跟进并获得成果，这点不论对绩效考核，或者对于未来找新工作，都很重要。过去我们遇到非常多读者，在找工作时履历只能写做了什么，但是写不出做的事情的影响力，这往往是因为没有去追踪上线后的收益。

阅读更多

在谈完以上的流程，接下来我们会进一步谈在上线过程中要特别注意的事、避免踩到的误区。 这些点我们在 E+ 成长计划的主题文都有更详细谈到，推荐感兴趣的读者阅读。

本文为 E+ 成长计划的深度内容，截取段落开放免费阅读。欢迎加入 E+ 成长计划阅读完整版本 (点此了解 E+ 的详细介绍)。