在本文中，您将了解保持部署序列运行的复杂性。
作者：Tyler Cipriani，Wikimedia基金会发布工程部工程经理
上周，我和我的一些Wikimedia基金会（WMF）同事讨论了我们如何部署代码——我彻底搞糟了。我变得太复杂太快了。后来我才意识到——要解释部署，我需要从谎言开始。
M.Jagadesh Kumar先生解释：
“每天，我都面临着解释一些复杂现象的两难境地[……]为了实现我的目标，我会“向学生撒谎”。”
这个想法来自特里·普拉切特的“对孩子撒谎“-一个错误的陈述，导致更准确的解释。通过近似逐渐接近真理。
这篇文章的每一部分都是一个微妙的谎言，但大致正确。
释放列车
我要说的第一个谎言是我们每周部署一次代码.
每周四，Wikimedia发布工程团队向所有用户部署MediaWiki版本978个维基.“发布分支”是198个不同的分支，每个分支用于mediawiki/核心,mediawiki/供应商、188个MediaWiki扩展和八个皮肤，它们通过git子模块捆绑在一起。
“渐进”卷展栏
下一个谎言更接近事实：我们不会在周四部署；我们从星期二到星期四部署.
这个名字很聪明TrainBranchBot（列车分支机器人）每周二UTC凌晨2点创建每周火车分站。
- 星期二
- 星期三
- 星期四
- 部署到剩余的320个wiki，包括我们最大的wiki：英语维基百科
渐进式卷展栏使用户有时间发现错误。正如Risker在Wikitech-l邮件列表:
“即使是最好的开发人员和最好的测试系统，也不可能总是捕捉到实际用户会发现的问题，其中一些用户比编写或QA人员更熟悉扩展的目的、预期结果和更改对扩展的影响。”
漏洞
现在我接近了真相：除了星期五，我们每天都部署.
振作起来：我们不会编写完美的软件。当我们发现严重的错误，他们封锁释放列车-例如，在解决阻塞问题之前，我们不会从Group1升级到Group2。我们通过以下方式解决阻塞问题后传发布分支的补丁。如果这个版本中有bug，我们会在主线分支中修补该bug，然后git cherry-pick该补丁到我们的发布分支并部署该代码。
期间，我们每天部署三次后端口后台部署窗口。除了回端口，开发人员还可以选择在回端口部署窗口中部署新配置或启用/禁用功能
发布工程师训练其他人每周两次部署后场.
紧急事件
我们星期五部署当有主要问题主要问题的例子有：
- 安全问题
- 数据丢失或损坏
- 服务的可用性
- 防止虐待
- 功能严重丧失/可见破损
我们避免在星期五部署，因为我们有一个小团队来应对事件。我们希望这些人周末远离电脑（如果他们愿意的话），而不是对紧急情况做出反应。
非媒体Wiki代码
Kubernetes上通过helm部署了42个微服务。有64个微服务在裸机上运行。服务所有者在列车流程之外部署这些微服务。
我们协调部署部署日历wiki页面。
整个真相
我们每周逐步部署大量MediaWiki补丁（150到950个）。每周有12个后台窗口，开发人员可以在其中添加新功能、修复错误或部署新配置。开发人员可以按照自己的速度部署微服务。
重要资源：
更多资源：
多亏了@布伦南,@格雷格,@克西伯特,@Risker公司、和@VPuffetMichel公司阅读这篇文章的早期草稿。反馈非常有用。请继续关注“我们如何部署代码：第二部分”
关于此帖子
这篇文章最初出现在Phame博客，《做必要的事》，2021年9月27日
特色图像积分： 文件：Union Pacific 844，Painted Rocks，NV，2009（crop）.jpg,04_15_09_162xp_-_Flick_-_drewj1946.jpg:德鲁·杰克西奇，衍生功：布鲁斯1ee,抄送BY-SA 2.0
.jpg&from=en&to=zh&token=&monLang=zh){kind=link}
