正儿八经

前后端关于CMDB的交互决定选用GraphQL，因为第一次听说就抓紧时间了解了以下是个什么东西。

GraphQL干嘛的？

GraphQL语言致力于提供一种直观的弹性语法系统，用以描述客户端程序设计时的数据需求以及数据交互行为。

说的直白点就是能让API设计变得更加的灵活，你想要什么数据就给你什么数据，不多不少。

实践

目前只有CMDB那一块使用的GraphQL，其它的前后端交互还是用的传统的方式。

不过这并不影响我对它的兴趣，新东西总是喜欢琢磨琢磨，更何况GraphQL有大厂的背书，那证明它的潜力是巨大地。

• 传统的api设计，如果想要多种场景公用一个接口，比如都是获取用户信息，A场景需要name，B场景需要name+sex，C场景需要name+introduction，很显然都是获取用户信息，但是每个场景要求的数据不一样，如果简单粗暴的直接返回整个用户信息，很显然不太科学，极端一点假设用户有20个字段，调用方只需要一个字段，你给20个字段完全是浪费，另一种方案是写三个接口，但是三个接口很显然太冗余了，所以通常是公用一个接口，但是共有一个接口就肯定免不了一堆逻辑判断,此外，这样还会造成不同业务之间的耦合，每次发布都需要各个业务场景一起测试和回归。

这种时候痛点就出现了，不重用接口则没法提高开发效率，重用接口则会有这些问题。

这个时候GraphQL就体现它的优势了，我认为它的出现就是为了解决上面的痛点。出现上面的问题的根本原因我认为在于，前端不能直白的告诉后端我要什么数据，必须通过后端经过对应的翻译转换，因为前端没有合适的方式来告诉我们A只需要name，B只需要name+sex，它可能就给我们一个userId然后给个businessCase然后我们根据businessCase来进行逻辑判断，进行数据查询，进行数据筛选以及过滤。

GraphQL

花点时间写这个，是因为觉得GraphQL算是开阔了我的技术视野，我们其实还用的很浅，他的一切皆是图、API无版本（某些场景）的思想，以及schema、别名、片段、指令、mutation、元字段等概念让GraphQL灵活的像猴哥，至少目前我们没有遇到有什么场景是满足不了的，至少对于技术浅薄的我来说是有开到脑洞。

我为什么要放弃RESTful，选择拥抱GraphQL

graphql工具社区

学习地址：

这是我用nodejs实现的很简单的demo：

这是通过howtographql搭建的demo

https://flaviocopes.com/graphql-vs-rest/

本文引用的内容，如有侵权请联系我删除，给您带来的不便我很抱歉。

这两天看了有人推荐的约翰·伯格在BBC的纪录片《观看之感》，这部纪录片开始通过讲艺术中的绘画（油画），然后讲解油画的内容，最后过渡到当今（70年代）社会的海报（广告）。

我这人是个粗人反应也比较慢，看到最后瞬间才如醍醐灌顶般了解这个纪录片讲述的东西，想在这儿写下感想….

但是资历太浅写不出来，后面想通了再回来补，现在就记录下现下我的思考。

感触

一听到艺术都觉得那是个高层次的是在生活之上的，其实可能不是我们传颂的那样，它的内容最终都是反馈到世俗生活中的，所以这样传统的认知是值得商榷的（约翰·伯格甚至是批判这种认知），整个纪录片我得到的信息是，告诉我一个词叫“欲望”，其实不管是油画还是其复制品还是现在的海报背后都隐藏着人们对某一方面的欲望。

所以其实你会发现现实中很多东西其实是被设计的，在比较深层次的地方他们可能会很可怕的引导你的思维方式、你的诉求、你的认知…，表面上可能会影响你穿什么、吃什么、喜欢什么…，这让我想到了一本书《娱乐至死》，大家有兴趣可以看下我觉得很有意义的一本书。

节目最后伯格大叔也说了，纪录片仅代表他的观点，具体怎么看还是取决与我们自己。所以我们活着一定要多些思考，多换角度思考，多想想为什么，不要轻易听信别人，也不要懒得思考…

本文引用的内容，如有侵权请联系我删除，给您带来的不便我很抱歉。

以前我对code review是抗拒的，原因在于两方面：

1. 总感觉有点脱光了让人看的感觉，没脸。
2. 觉得是浪费时间，研发周期时间都不够还做什么code review。

不过后来发现之前的自己是多么愚蠢

Why

• 倒逼团队成员写出更有质量的代码

  （基于编码规范等），让代码可以更好的组织起来，有更易读，有更高的维护性，同时可以达到知识共享，找到bug只是其中的副产品

• 确认自己的设计和实现是一个清楚和简单、正确的

  并且通过review找到问题代码，减少错误和暗坑

• 让更多的人了解你所写的模块，并能促进相互学习对方的长处和优点。

• 提前暴露影响性能和安全的问题

When

• 自动化测试之后，提测之前
• 前后端联调之后（如果自动化测试还没实现）

What

评判标准

• 编码规范（比如后端《阿里编程规范》，前端ESLint）
• 需求覆盖度是否100%
• 测试用例覆盖度至少满足80/20原则

How

• 提升团队意识，让大家知道code review的好处和重要性，切忌别把时间安排与code review拿在一起说，它们是两回事，时间够不够条件够不够跟code review好不好无关。
• code review落实到产线的专项目标，指定责任人。
• 组件core view 团队，定义code view的关注点，持续改进。

首先为什么需要详设？

肯定有人会喷，现在都谈敏捷了，你那是瀑布那一套了，现在谁还弄详设，然后就被鄙视了。如果是这样我就想问下，什么是敏捷？什么时候应该敏捷？先回答好了这两个问题再BB，哥也是经历过敏捷的人，13年在一家做数字工厂的创业公司，被公司副总忽悠做项目经理，当时作为一个码农的我来说，本身比较迷茫感觉天天敲代码不是我要的，觉得白富美离我太远。所以就想做产品经理，憧憬做一个响当当的产品出来，享誉中国，当然我得解释一下，此产品经理不是被玩坏的那种UE产品经理，而是正儿八经的产品经理。刚好遇到此副总，跟我聊了后就看上我了，美其名曰看上我的才，觉得我有当产品经理的潜力，然后我就飘飘然的去了。去了之后就让我先从项目经理干起，这儿的项目经理只管项目（需求调研、文档编写、项目资源协调…）不管技术。副总当时推得就是敏捷，因为本身干的是传统行业，一开始都是瀑布过来的，副总觉得瀑布有很多问题，所以准备推敏捷，我当时也是第一次接触敏捷，所以老大丢给了我一堆书，其中一本我记得是叫《敏捷项目管理》的书，然后就让我抱着啃，也恬不知耻的跟着其它项目组体验了敏捷的落地…。那段时间是我悠闲、迷茫的时光，一开始用latex跟公司弄宣传册，然后跟项目，去鸟不拉屎的地方，夏天跟客户喝着“枝江”聊着需求，其实挺怀恋的…。

扯远了，后来在现在的公司，公司又请人做了一次敏捷培训，内容其实跟我之前看的书差不多，只是里面有一个概念是我比较深刻的就是讲师说了一个词语叫“小瀑布”，大概意思就是取敏捷和瀑布的各一部分。为什么呢？就是因为传统的瀑布确实是太重周期太长了，而且对客户的要求高，因为瀑布都是白纸黑字写好合同定功能需求的。你想想客户如果没想好，那是不是就麻烦了。但是事实是往往客户是不可能百分百知道自己要什么的或者说不可能百分百描述清楚自己要什么的。这个时候敏捷就有优势了，敏捷在我看来其实就是工作理念的转变，讲求的是快速迭代，讲求用户参与，讲求跨职能，这样就能很大限度的避免走偏。

小瀑布在我们团队是咋用的呢，主要包括：

1. 首先团队是跨职能的，需求、产品、测试、研发都同属于一个团队，且团队的目标是一致的。
2. 前期除了User Story，还会进行需求评审，会出UCD文档，研发会出详设。
3. Daily Scrum不强制要求。
4. 没有Sprint Review

为什么我们会这样是因为我们本身不是一家互联网企业，对快速响应要求没那么高，我们是一家传统的toB企业，有自己的产品，很少接项目做，有稳定的渠道，不过也存在瓶颈，在这样的情况下，做新产品，我们则采取了现在的小瀑布的形式。至少目前来讲是很适合的。

ok，扯得有点多了，我们还是来说说详设。

0.1版详设

因为之前的详设没有一个特别正式的模板，接着0.2功能迭代需要写详设，领导让我和另外一个同事整一个详设的样板出来，跟领导过了几次，搜集了一下意见，最终中心思想只有一个，让新旧研发、测试、技术大佬都能看明白。

所以最终出的模板是这样滴：

这个模板稍微复杂了一些，但是他的好处在于说明了上下文，说明了依赖项，说明了核心逻辑，所以基本上出来的东西大家都能看懂，也能而且能评估难度和工作量等。

0.2版详设

这版详设是在产品0.3.3迭代后出现的修改，是在0.1基础上的一些精进，精进了依赖项和核心逻辑说明。

• 0.2把外部依赖项单独拎出来，这样能更加清晰表述自己所需要的支持，并且让对方知道。
• 0.2把核心逻辑也着重提出来，0.1核心逻辑更多在于文字描述和UML图，0.2的要求是用伪代码+UML的形式进行核心逻辑的说明，核心思想就是贴近代码让详设更加实用。

详设最实用的地方：是为了让你思考更加缜密，并且获得反馈。

未来的期望：

当然这版详设也不是最终版，以后会持续精进，最终的目标是直接不要文档。

甚至我们刚进的一个架构师提出的愿景是：全部用类似单元测试的代码+注释的形式写详设，详设是否存在问题，看单元测试是否通过，我觉得是很美好的…..路很长。

名词解释

Sprint

可理解为一个迭代

Scrum

Scrum 可以理解成是一个框架，此框架让产品管理和工作技术的相对成效更加清晰地显现出来，以便您可以持续改进产品、团队和工作环境。

Daily Scrum

每日站会

User Story

用户故事，可以理解为一个场景或者一条需求。

兽爷的《疫苗之王》原篇。做个保留，作为一名小女孩的爸爸，仅以此文诅咒他么的长生生物之类的不良商家以及背后的各种势力各种任务，滚你妈的祖宗十八代。诅咒他们得癌症了发现能治，然后吃药发现吃的是假药，然后就只有等死。气死老子了，一想到自己女儿就气不打一处来。

之前在12-Factors时提过我们在搭一个脚手架，这篇简单介绍一下，老话说得好再丑也要出来吓人嘛。

项目模块

项目模块是基于maven做的项目生成脚手架，基于此脚手架生成 maven 项目模块， 开发人员能快速的基于模版进行开发，减少前期熟悉开发框架时间。同时 也通过此模版来统一平台开发规范，实现工程能力提升，沉淀工程规范。

结构说明

• app-bom 工程依赖管理.

• app-manager 工程胶合层，service 层通用能力下沉，复杂 dao 组合.

• app-repository 数据操作层，与数据库进行交互.

• app-rpc-api 服务向外暴露的 rpc api 接口.

• app-service 服务业务逻辑实现.

• app-web 服务 restful 接口.

maven脚手架

最近项目的0.2阶段需要加上权限功能，产品方给了一个需求文档，让我们参与共创。所以借此梳理梳理权限的东西。其实万变不离其宗，我觉得基本上权限设计都是基于RBAC模型来设计的。

我认为的权限应该是分为两种：

• 应用权限。也就是我们通常说的系统权限，比如用户、角色、权限等等。
• 认证。通常说的是验证某个用户是否具有访问系统的权限，实现方案比如OAuth、OAuth2、Open API等等。

权限复杂度的设计依业务场景而定，我是基本上做的都是toB，所以权限这块会相对复杂些。不同的toB系统权限设计肯定也不同。不过我觉得大体可以分为三种toB权限设计场景。私有云、私有云（对客户定制开发并部署在客户现场 的我也归为私有云）、混合云。当然我比较熟的是公有云和私有云的，混合云的我还没涉及到过，不过我觉得是混合云应该和公有云的权限设计比较接近。

下图我参与过的某toB平台，我理解的权限设计。

租户那块为什么单独标注呢，租户是一个比较大的概念，通常表名一个公司或者个人。

下面是我另外参与的私有云项目的权限设计。

这个权限你会发现有一个域的概念，是因为我们的客户是集团性质的客户，会有总公司、分公司、事业部等概念，因为每个分公司或者事业部大体上都是独立运营的，但是他们又是属于一个集团，所以我们出现了域的概念。一个域可以理解为一个公司或者事业部但是我们不强关联，域是扁平的增加了灵活性。还有一点需要注意在这儿部门（组织）是不纳入权限的，我们使用角色来控制，为什么还需要部门，是为了让角色更丰满，部门可为角色打上标签，客户也好理解。同时也减少了复杂性。

名称解释

资源

因为要打造的是一个APM系统，所以里面会涉及到CMDB，资源这个名称就是CMDB来的当然一般我们叫CI（具体一个配置项，也叫CI实例），要详细讲就要讲到CMDB了，要讲CMDB那就复杂了，不是一两篇能说清楚的，后面有机会我会试着讲讲我理解的CMDB和CMDB在我们系统是怎么定义以及怎么用的。

RBAC

基于角色的访问控制，所以你会发现这个模型能满足大多数的权限设计。至少我没见过没有角色这个概念的权限设计。

google和博客说的更清楚

干了一段时间前端，老想着什么时候能搞明白点什么。要搞明白点前端的东西，前端的技术五花八门的，顾不过来，既然顾不过来那就别顾了，找到他们的基石就对了。不管技术怎么变，最终都得在浏览器解析。所以我想着先搞清楚浏览器是咋工作的，可能会让我对前端没那么惊慌。

一google找到了这个姐妹-Tali Garsiel，看到有好几篇文章都是基于她的文章来的。这姐姐人干了N多年的前端开发，看了各个开源浏览器的源码，用尽洪荒之力总结出了这篇文档http://www.taligarsiel.com/Projects/howbrowserswork1.htm。那我也厚颜无耻的用她写的文章作为了解浏览器的入门。虽然文章的年代比较老，但是浏览器的核心概念是不变的，这点从近年来大家的解读可以看出来。

文章主要是针对开源或者部分开源的Chrome、Firefox、Safari。文章有很多章节，我就挑我喜欢的来说了。

The browser’s main functionality

这个章节我了解到一个很有意思的事情就是浏览器的界面，其实是没有任何规范或者说标准的，几大浏览器厂商你抄我我抄你最后大家就基本上长得一样了。比如都有地址栏，都有工具栏等等。

所以浏览器基本上都有以下几大功能：

• 用来输入 URI 的地址栏
• 前进和后退按钮
• 书签设置选项
• 用于刷新和停止加载当前文档的刷新和停止按钮
• 用于返回主页的主页按钮

The browser’s high level structure

这章节讲的是浏览器的主要结构。

• 用户界面 包括地址栏、前进/后退按钮、书签菜单等。除了浏览器主窗口显示的您请求的页面外，其他显示的各个部分都属于用户界面。

• 浏览器引擎 在用户界面和呈现引擎之间传送指令。

• 呈现引擎 负责显示请求的内容。如果请求的内容是 HTML，它就负责解析 HTML 和 CSS 内容，并将解析后的内容显示在屏幕上。

• 网络 用于网络调用，比如 HTTP 请求。其接口与平台无关，并为所有平台提供底层实现。

• 用户界面后端 用于绘制基本的窗口小部件，比如组合框和窗口。其公开了与平台无关的通用接口，而在底层使用操作系统的用户界面方法。

• JavaScript 解释器。用于解析和执行 JavaScript 代码。

• 数据存储。这是持久层。浏览器需要在硬盘上保存各种数据，例如 Cookie。新的 HTML 规范 (HTML5) 定义了“网络数据库”，这是一个完整（但是轻便）的浏览器内数据库。

这几个组件中，最主要的或者说前端开发最应该关注的就是呈现引擎了，你想嘛，你做的everything最终不就是为了让浏览器把你想要的效果呈现给用户么，呈现引擎就是干这个事的。

这个地方可能需要注意一下，可能会有疑惑为什么javascript单独拎出来了，请注意啊，javascript它最初的作用就是操作dom，从而实现一些动态效果而发明的。所以它本身是不能直接作为呈现给用户的，需要一个编译执行的过程，所以不属于呈现引擎的组成部分。当前现在javascript不仅用于前端开发了，后端也常常作为某种函数脚本的存在，比如java8以后的MapReduce可运行对应格式的js脚本、java的mango客户端也能用js脚本…

呈现引擎先主要有两种一种是Firefox 的Gecko，这是 Mozilla 公司“自制”的呈现引擎。而 Safari 和 Chrome 浏览器使用的都是 WebKit。不管是哪一种引擎都是为了让浏览器能更好更多的支持内容的呈现。虽然现在浏览器能呈现的内容远远不止HTML+CSS，但是主要的还是对html和css进行解析呈现。

如图所示，呈现引擎一开始通过网络组件请求需要呈现的文档内容，拿到内容后开始解析，首先解析html，把html分割成大量的标记（标签），进而把每个标记转化为一颗dom tree上的节点，同时解析css样式，并和dom tree转换为另一种树：Render Tree（该树包含有多个视觉属性的矩形，并存在排列顺序）。

接着根据Render Tree进行布局，因为呈现树上包含有视觉属性以及顺序，所以可以为呈现树里各个节点（矩形）分配坐标。

分配好坐标以后由另一个组件用户界面后端进行树的绘制。最终呈现给用户。Gecko，WebKit略有不同但是总体的流程是一样的。

整个过程是渐进的过程，浏览器不会等着所有html文档都解析完再呈现，而是解析过程中就开始构建呈现树和设置布局。在不断接收和处理来自网络的其余内容的同时，呈现引擎会将部分内容解析并显示出来。

专业解释：HTML 经过解析生成 DOM Tree；而在 CSS 解析完毕后，需要将解析的结果与 DOM Tree 的内容一起进行分析建立一棵 Render Tree（呈现树），最终用来进行绘图。Render Tree 中的元素与 DOM 元素相对应，但非一一对应：一个 DOM 元素可能会对应多个 renderer，如文本折行后，不同的「行」会成为 render tree 种不同的 renderer。也有的 DOM 元素被 Render Tree 完全无视，比如 display:none 的元素。

这儿需要注意的是，html的解析是正向的从上到下（从左到右）的（从根节点开始），而css是逆向的从下到上（从右到左）的。为什么html是从上到下的，这个很好理解，你想想html解析后是一棵树，你想想树的构成肯定是先有个主干然后再有分叉，这样才是一个整体，不然不就是一盘散货么。那css为什么就一定要从下到上呢，通过下面的叙述你会知道如果css也采取从上到下的顺序，那dom tree和style rules两个需要对上眼的消耗是很大的（因为通常dom节点多，css样式也多）,从概率上来讲逆向匹配的概率是远远高于正向匹配的概率的。

专业解释：在建立 Render Tree 时， DOM Tree 中的元素需要根据 CSS 的解析结果（Style Rules）来确定生成怎样的 renderer。对于每个 DOM 元素，必须在所有 Style Rules 中找到符合的 selector 并将对应的规则进行合并。选择器的「解析」实际是在这里执行的，在遍历 DOM Tree 时，从 Style Rules 中去寻找对应的 selector。

如果正向解析，例如「div div p em」，我们首先就要检查当前元素到 html 的整条路径，找到最上层的 div，再往下找，如果遇到不匹配就必须回到最上层那个 div，往下再去匹配选择器中的第一个 div，回溯若干次才能确定匹配与否，效率很低。

逆向匹配则不同，如果当前的 DOM 元素是 div，而不是 selector 最后的 em，那只要一步就能排除。只有在匹配时，才会不断向上找父节点进行验证。其实更深入的理解需要深入了解Html Parser和css Parser的工作过程。

关键字解释：

style rules

源引：

为什么是windows版，能别问么。穷啊。这几款是我自己在用的。

Everything

文件搜索工具

Wox

集合各种功能的搜索工具，强大的令人发指那种。

Seer

预览工具，敲空格就能预览各种文件，也是超好用。

Listary

定位，查找文件等功能。

Snipaste

截图工具轻巧好用。

Mobaxterm

免费的远程网络工具，功能非常多，几乎提供了所有重要的远程网络工具（如SSH、X11、RDP、VNC、FTP、MOSH等），以及Windows 桌面上的Unix命令（bash、ls、cat、sed、grep、awk、rsync等）。

Photo by Joanna Kosinska on Unsplash

OBS-Studio

录屏工具。

Typora

MD文档工具。

Google 扩展

Kami、Pocket、Fatkun、沙拉查词、Adblock、OneTab、Scroll To Top、Grammarly

本文引用的内容，如有侵权请联系我删除，给您带来的不便我很抱歉。

源引-冯大推荐的少数派：

背景

现公司是传统的ToB业务公司，现在要新开一条产品线，因为公司的之前的产品已经10年了，因为技术等的限制，无法应对现在的快速迭代，公司高层想用现在流行的玩法，寻求突破，刚好之前那家公司的leader，支付宝出来的刚从公司离职，他和事业部的总经理是高中同学，所以瞌睡遇到枕头，就找到他来领头做个事，事业部研发中心在天津，他想做这个事必须得带几个自己信得过并且好用的人（是滴，我很好用），所以我和另外一个同事就通过他的内推去了天津（我是对现在的公司及其失望），那番场景那真就是，新老两派之间充满爱意的碰撞，我们抛弃了之前事业部的所有技术积累，全部从0开始。

这篇文章讲的就是在开垦一个后端脚手架的过程中发现了12-Factors，其实很早以前就听过12-Factors，这次逮着机会好好了解下，刚好最近看jimmysong翻译的《迁移到云原生应用架构》，里面提到了12-Factors，这套理论看来是没过时的，借机学习学习。

I. 基准代码

一份基准代码（Codebase），多份部署（deploy）

我们项目是采用类似git flow的方式来管理代码，首先每个应用肯定只有一份基准代码（master），不管是新功能的开发、bugfix、hostfix、release、tag等最终都是基于master的。这样就保证了所有部署的基准代码相同，但每份部署可以使用其不同的版本

II. 依赖

显式声明依赖关系（ dependency ）

每个应用都有自己的依赖清单，前端是package.json，后端是pom.xml。每个应用都会显示的列出依赖。

III. 配置

在环境中存储配置。

每个应用都有自己的配置文件（yaml），针对不同的场景有不同的配置，发布、预发布、测试等。杜绝把配置写死在代码里的情况发生。

IV. 后端服务

把后端服务(backing services)当作附加资源

数据库、消息队列、数据中心等都是作为基础设施存在的，每个应用是与这些组件都是松耦合。不足是现有的客户场景对可能只能做到逻辑上的隔离，比如数据库虽然逻辑上和应用是隔离的但是物理上可能在一个主机上，因为客户现场可能就跟我们提供几台机器。

**
V. 构建，发布，运行**

严格分离构建和运行。

项目采用的是阿里云的ci/cd方案，构建、发布、运行都是分离的。每个版本对应唯一ID。

VI. 进程

以一个或多个无状态进程运行应用

12-Factor 应用的进程必须无状态且 无共享 。 任何需要持久化的数据都要存储在 后端服务 内，比如数据库。

项目中，进程中无共享，权限、session等都存到redis中。

VII. 端口绑定

通过端口绑定(Port binding)来提供服务

这点没什么说的，项目所有的应用提供服务都是通过端口与应用绑定的。

VIII. 并发

通过进程模型进行扩展。

这一点没做好，后端采用的java语言，都知道java是典型的线程模式。所以只能给应用分配相应的资源，让其能纵向扩展，但其实效果不是很好。当然我们有比较简单的方式可以使其进行横向扩展，即每个应用部署多实例的方式进行横向扩展，不过目前没有实践。后续会完善。

IX. 易处理

快速启动和优雅终止可最大化健壮性。

该原则要求应用可以瞬间启动和停止，因为这将有利于应用快速进行横向扩展和变更或者故障后的重新部署，而这两者都是程序健壮性的体现。

快速启动是做到了，但是优雅的终止还带完善。

X. 开发环境与线上环境等价

尽可能的保持开发，预发布，线上环境相同。

我们的发布部署统一走的阿里云效的流水线，流水线的配置除了机器不同其他都一样。

XI. 日志

把日志当作事件流。

这块没做好，待完善。个人觉得是很有必要的，后期会酌情加上日志处理分析组件。从日志输出到读取，到分析，到加工，到视图一条龙服务。

XII. 管理进程

后台管理任务当作一次性进程运行

官方说明：

开发人员经常希望执行一些管理或维护应用的一次性任务，例如：

• 运行数据移植
• 运行一些提交到代码仓库的一次性脚本。

一次性管理进程应该和正常的 常驻进程 使用同样的环境。这些管理进程和任何其他的进程一样使用相同的 代码 和 配置 ，基于某个 发布版本 运行。后台管理代码应该随其他应用程序代码一起发布，从而避免同步问题。

我理解意思就是应用的管理工具应该随产品一起提供，并且管理任务应该从生产环境中运行最新版本的生产代码的机器上执行此任务。换句话说，从与生产相同的环境中运行一次性管理任务。而不要做类似直接对数据库运行更新这种操作，我理解意思应该是有配套的管理工具而且管理工具是与生产环境同步的，如果需要做一些一次性的维护管理任务，比如数据库移植、A/B测试等任务时不要做手动去改数据库这样很容易造成环境搞乱的操作。

这点在我们项目还是比较弱的，0.1阶段基本上没有统一的管理工具，大家都是通过手动改库等操作达到目的。后期会争取做到这一点。

12-factor 到底好不好，适不适用，我觉得不是绝对的，目前我们遵循这套是因为我们觉得它对我们有指导意义而且是有效的够用的。

源引：

本文引用的内容，如有侵权请联系我删除，给您带来的不便我很抱歉。