※ 引述《hiefal (Bushiroad原厂打手)》之铭言：
: 各位晚上好
: 我刚进入后端开发一阵子 经验还不多
: 最近拿到了一份offer 目前各方面条件感觉起来都不错
: 面试官给人的感觉以及技术都很好
: 但是似乎步调有点快 主管看起来也比较疲惫(可能是因为要on call)
: 其中对方有提到产品的Release周期为一个月一次
: 想请问各位这样的Release速度是不是太快了?
: 会不会容易因为时程关系
: 反而不利于技术成长呢?
: 大家公司的release周期大概都是多长呢
先快速回答这题的答案，
我待过的不同团队有两周上线一次、每天上版的，
也有一天上很多次（每个人都可以 deploy）的团队。
原文下面的推文也满多人提到跟工作方法或产品型态有关，
我写了一篇文章来分享自己过去在团队做 Release Management 的经验，
以及刚踏入 PM 工作初期时总是搞不清楚的技术名词解释，
这部分如果解释有误还请大家多多回馈。
Medium 好读版：http://a0.pise.pw/RUWUK
文章内容包含：
- 为什么不同产品团队 Release 的频率会有这么大的差异？
- 产品上线流程相关的名词解释
- 实务工作流程、每天上版之我痛苦的一天
▍为什么 Release 频率会有这么大的差异？
一、产品类型与服务对象不同：自有产品 vs 接案团队
自有产品的团队对于多久上一个新版本、每个版本要涵盖多少改动的决策可以较为弹性。
接案团队则取决于客户的喜好、习惯与信任度，尤其若是新产品、新网站上线，客户通常会要求功能与页面都非常完整才会一次上线，上线前也会有客户验收、测试与来回修改的时间，所花的时间就很容易比前者陆续优化现有产品的状况还要多非常多。
二、工作方法与目标不同：敏捷式开发 vs 瀑布式开发
在敏捷式开发（Agile）方法中，核心价值是快速的开发、测试、上线，透过小而快速的迭代来从市场与使用者身上学习，新的需求可能会在每次新版本释出后因为收到的回馈而被修正，贴近市场与使用者来持续优化产品。
在这种情况下搭配自动化的 CI/CD 增加释出新版本的频率是必要的，举例来说 Scrum 方法论常见的跑法是每两周一个 Sprint，因此上线频率可能就是每两周一次。
在瀑布式开发（Waterfall）方法中，开发上有明确的顺序，如厘清需求、产品设计、开发、测试、上线，追求的是在开发的流程中每个阶段都要做好十足的准备，完成后才能进入下个阶段，也因此整个过程会花费较多的时间，适用于一些定义很明确的状况，例如串接第三方服务、接客户的案子、极端情境（edge cases）很多且需完整测试才能产生信任感的状况等等。这种情况下，一季、一年才上线一次也有可能。
▍产品上线流程相关的名词解释
产品、功能、改动最终的目标都是上线，亦即呈现在使用者面前、让使用者使用。这边可以分为两个部分，第一部分是程式码的改动被部署到正式环境（这篇文章主要分享的部分） ；第二部分则是这个改动被推到使用者面前的阶段，而这阶段又分为推到部分使用者面前做测试或实验，以及最终开放给所有的使用者的状态。
不论是跟台湾团队还是海外团队工作，我们在提到这些名词时几乎都是用英文称呼，也因此讲话总是中英夹杂，文章中我会尝试用中文来表达！
Deployment（部署、上版）
本身的意思是将程式码放到特定环境中，常见的环境包含开发环境（dev）、测试环境（test）、正式环境（production），有些团队中会在上线正式环境前有个模拟环境（staging, stg）来做整合测试或 E2E 测试。
在日常生活中当我们提到“今天有 deployment 吗？”可能就是只有没有新的改动要上线到正式环境当中，所以有时候 deploy 跟 release 这两个词会被混在一起使用。
Release（释出、上线）
这个词很容易让人误会，因为有时候我们将改动部署到正式环境中时，改动马上就可以被终端使用者看见并使用；但有时候我们会先只释出给一部分使用者、特定市场、做 A/B Testing，如果成果是好的才会是好的才会释出给所有使用者。
从工程师的角度来看，可能每一次的正式环境部署都可以算是 release，但从产品团队、行销团队、使用者的角度来看又会不同。
如果由我自己来定义的话，我认为这个新版本、新功能要有来自正式环境的流量与真实使用者使用时才算是 release，若只是给内部团队在正式环境测试，那也不能算释出。在这个定义下，rollout 也可以代表相同的意思。
Phased Rollout、Staged Rollout（阶段性释出）
承上，从部署完到完全上线中间有时候会有一个阶段性释出的过程，短则一周、长则几个月都是有可能的，这部分通常是由产品经理负责的。
这个阶段会做的事情就是内部测试、外部测试、蒐集回馈，如果有 bug、从使用者身上得到心回馈，也可能会在将产品改动或功能做得更完整后再释出给更多人。有些团队也会明定 Alpha Test、Beta Test、Release Candidate（RC）等不同阶段。
Full Rollout、Rollout to All（完整上线、释出给所有人）
经历过上面释出给一部分使用者测试、在特定市场试水温、用实验来观察数据变化后，若反应都很正向，就可以正式上线给所有人使用了。
当然也有可能在前面几个阶段发现新的改动并不值得上线，而直接取消上线、或是大改方向的状况。
Product Launch（产品发布、上市）
这个步骤则是在功能或产品释出给所有人后，选择对外公开公告新功能或新产品的阶段，通常由产品团队、行销团队（B2C）或客服与业务团队（B2B）负责，小则从在网站上推播、或寄信发公告给使用者，大至发新闻稿给媒体、举办大型记者会。
▍相关技术名词概述
以下再补充一些技术相关的一些名词解释，我刚开始 PM 工作时跟工程师讲话简直就是一头雾水！我毕竟不是工程师，就不深入说明每个名词的细节，单纯分享团队讨论时常出现的名词，有兴趣的读者可以自己再去深入研究这些主题。
Delivery（交付）
CI/CD 中，前者是持续整合（Continuous Integration），后者是有人说是持续交付（Continuous Delivery）、也有人说是持续部署（Continuous Deployment），这部分让我有点困惑，有时也会混著用。
其中一种说法是，交付代表程式码随时准备好能够被部署到正式环境中，因此是部署前的步骤；也有人说交付的程式码是小包小包的，而部署的程式码是一整个大版本；而若由我自己来说明差异的话，我认为部署（deploy）作为动词时，对象是环境；而交付（deliver）作为动词时，对象是使用者。
在某些公司会有 Delivery Manager 这个职位，通常由工程师背景、技术背景的主管担任。
Master & Branch（主线 & 分支）
产品上线会有持续有很多不同的版本，可以使用 Git 这个分布式的版本控制系统来做专案的版本管理。可以想像同时有很多个不同的工程师在为同一个产品开发新功能，使用者现在在正式环境看到的都是统一版本，然而每个工程师在自己的本地端会因为开发新功能而加了新的程式码，所以每个版本都不同，这时候版本控制系统就非常重要。
Master Branch 是最主要的主线，其他分支如 Dev Branch、Feature Branch、Release Branch、Hotfix Branch 等等，新的功能通常会开新的分支来开发，开发完成后会再合并（merge）回主线。
其他常见名词解释
- Push：将本地端的档案、程式码上传（推）到远端。
- Pull：把远端的程式码下载（拉）下来，类似于复制最新的版本到本地端，并将远端分支合并到本地分支，这样开发时才会是基于最新的版本。
- PR（Pull Request）：要求第三方、远端、其他分支拉自己的版本过去，类似于合并到其他人的版本上。
- Merge：把新的程式码合回去主线。
- Dependency：相依性，某段程式码跟其他程式码有关联，merge 的先后顺序可能会有差异。
- Conflicts：不同的版本之间在 merge 的过程中可能会有冲突，例如两个工程师虽然在开发不同的功能，但可能背后一些交错的逻辑是有相关的，这时候就要来解 conflicts。
- Rebase：同上，当有新的版本部署到正式环境，跟每个工程师在本地端开发的版本可能已经有不同，因此要整理本地端的版本，避免还在旧的版本上开发。
Build（建置、版本）
原则上就是即将部署的版本，会是一堆任务、功能、改动、Pull Request 的集合。团队会基于这个版本在模拟环境（staging env, pre-production env）做上线前的最终测试。如果在测试中发现问题，就会 merge bugfix to the build 然后重新测试，确保上线的版本是经过检验的。
Version（版本、版号）
每个 Build 都会有一个独特的版号，有些团队会以“日期”来命名，但另一个常见的形式是如 1.23.0 的三组数字，意思分别为 major.minor.patch（主版号.次版号.修订号），数字会随着新版本递增。第一个数字是大版本更新时、第二个是功能更新或新功能上线时、第三个是小型变动时，当前一个数字进位时，后面低阶层的数字会归零。
这种语意化版本的版号其实是有官方定义的：https://semver.org/
不过我会说每个团队都有自己习惯的定义方式，只要团队内部有共识、好管理就行了！
我的习惯是默认一般情况下只改变 minor 的数字（上面案例变为 1.24.0），patch 是留给 hotfix 使用（变为 1.23.1），major 则是底层架构大更新、整个接口大改版时才会更新（变为 2.0.0）使用机会较低。
Rollback（回滚、回复上一动）
当部署到环境中发生问题时，可以 rollback 回到该环境的上一个状态中。通常是部署到正式环境后发生问题，短时间内找不到问题而无法用 hotfix 解决，因此决定将正式环境回复到还没部署新程式码的状态。这种情况当然是愈少愈好。
Hotfix（现在一定要上线的紧急修正）
当正式环境发生了紧急且严重的问题，无法等到下一次版本上线，必须立刻修好的时候，我们就会马上上一个 hotfix。
它不是功能、也不是预料之中要上线的东西，且会立刻打断原先排程的工作，再怎么会拖，通常当天下班前一定要处理完，否则就会变成你今晚的恶梦。
▍产品上线实务流程
当团队还小、产品影响力不大时，每个工程师可能都有权限自己部署新版本到正式环境，这时只要工程师彼此能够沟通好就没问题了。Slack 也有一些插件让工程师可以很快速的部署，同时让其他在同个 channel 的团队成员得到更新。
随着产品团队长大，同时在动工的部分很多，上线这件事情变得愈来愈复杂，因此会需要有专门的人来负责，有些团队中会有专职的 Release Manager、Delivery Manager 来管理，有些团队则是由 Project Manager、Product Manager 一条龙来负责前期规划、开发到最后上线，另外一些团队则是将最后一哩路统一交给 QA Manager 来负责。
我有幸（还是不幸？）曾经担任过团队中统整产品部署与上线流程的负责人，在此稍微分享一下这个职位的工作内容。
我们的团队当时几乎是每天上新版（daily deployment），状况好时顺着流程走就没问题，但出现问题时只能全心全意处理上版的问题（first priority!）几乎从早到晚都在忙这件事，根本不可能专心做产品工作。
每天上新版的流程
10:00 — 开始部署新版本至正式环境
确认前一天的 build 是否测试完成且没问题，若没问题则通知负责部署的工程师上新版本到正式环境。
同时在公司群组发送 Release Notes 让大家知道这个新版本的改动。
11:00 — 部署完成、正式环境检查
正常情况下已经部署完成，PM 与 QA 团队会在正式环境确认上线的内容没问题。
如果有问题的话，端看问题的严重程度，决定是否需要上 hotfix，还是需要整包 rollback，同时确认当天这个版本是否还能重新测试完上线、是否会影响到后面的时程，重大问题还要写日志纪录跟检讨。
若问题没有非常严重，可以将它视为一般的 fix 并放到下一个版本上线修正。
12:00 — 为下一个 build 做准备
整理下一个 build 要包含的内容、判断准备上线的内容的优先级、跟 PM 团队确认隔天要上的功能与改动。
同时检查这些任务之间有没有 dependency、以及会不会有太多重大的改动在同一个 build 中，或是过于重大的改动需要提前通知前他部门。
其实这些通常不会当天才确认，但要请工程师 merge 之前还是要做好检查。
若没问题就通知负责部署的工程师开始建置下一个 build 的测试环境。
14:00 — 开始测试下一个 build
当工程师已经将下个版本一整包的内容放到测试环境后，QA、PM 就可以开始测试与检查，包含自动化测试与手动测试。
自动化测试的主要测试项目为目前线上已有的基本功能与模组，避免新的版本影响到原有功能，而新功能的自动化测项则是会边开发边加进去，逐渐提高代码覆蓋率（code coverage）。
手动测试时会检查要新上线的功能、改动的前端状况，包然使用情境、使用流程、UIUX 的呈现状况。
18:00 — 下班前随时确认测试状况、为隔天的部署做准备
确认测结果，理想状况是当天当测试完毕，隔天早上一上班就可以让新版本上线，也因此在前一天下班前要将 Release Notes 都写好，并事先预告团队。
不理想的状况是测试测出问题，就要在这个 build 中 merge 新的 fix 进去、严重点可能直接 revert 某一段程式码（也就是某个功能或改动不会在这一包一起上线），然后重新部署到测试环境后重新测试，因此如果确定隔天没办法上新版本，一样要预告团队成员。
不只是 Release Manager 更是 Issue Manager
这个工作难的地方在于当新版本正式部署到正式环境时，可能会出现问题，每次的问题可能又不同，这时候快速应对跟危机处理非常重要。我们也因此订定了一些基本规定让未知风险的危机处理可以更有效率。
1. 规定上版时间：周五不上新版，因为若周末出问题没人能处理；下午四点以后不上新版，因为太接近下班时间。
2. 讨论好 hotfix 的定义：如果每个小问题都要上 hotfix 那我们整天光处理这件事就好了，因此事先定义好多严重的事情才达到我们必须上 hotfix 的紧急情况很重要。
3. 将工作流程文件化：其他部门（甚至不熟悉这套流程的 PM）可能会认为上线新版本、上线一个 hotfix 是一件非常快速又简单的事情，但是根本不是啊啊啊！因此要尽量将工作流程文件化，方便跟其他团队分享流程、也方便内部团队的教育训练。
总之在这个位置上，我追求的就是上线上的快、改动频率高（新功能多）、downtime 时间少，而且每天上线的内容的优先级是合理的，总归一句就是“低风险的快速迭代”。如果你的团队也决定要走每天上线新版本这条路，要有每天都像在打仗的心理准备！
▍结语
以上分享我不专业不全职的工作方法，这方面中文的分享似乎不多（或是我下错关键字…）下面分享一篇也是中英夹杂的文章，以及 David Ko 的这篇《从 Scrum 到 Kanban 的过程》也有提到这个角色。
欢迎专职的 Release Manager 来分享全职做这份工作时完整的规划与做事方法！我真心敬佩
兼职 Release Manager 时的工作吃力不讨好，我们整个产品团队当时有好几个产品经理、scrum team、feature team，大家都希望自己的东西赶快上线，毕竟东西没上线就跟不存在一样、一点影响力都没有！
然而我对优先级的想法与其他 PM 的想法有时不同（我也很想先上我自己负责的产品啊啊啊啊但又一直提醒自己不能球员兼裁判），协调什么先上、什么后上真的是一门大学问，而为了赶每天的时程难免忙中有错，真的是沟通技能和抗压性要点高一点才能安稳妥当地做好这份工作。
不过我在做这份工作时也更完整的理解了整个产品从脑中构思到实际上线的过程，以及整条道路上会遇到的阻碍，更重要的是，如何从产品规划与开发的时候就事先辨认与降低这些风险。
以上抛砖引玉，希望大家也可以多多分享自己团队 Release 的流程和管理方法！