上周那个帖子炸出来好多人。
说的不就是咱自己么。
持续集成与持续交付又一次出现卡死状况，眼睛紧盯着屏幕不停地转圈，在那十几分钟的时间里什么事情都没办法去做，然而又胆战心惊真的不敢去做别的事情，就怕一不小心错过了。
压根儿不是代码致使崩溃，仅仅是一个镜像，两三个G大小，好似一个重得要命的行李箱，每一次上线都得拽着它在整个世界到处跑。
有人在评论区进行自嘲，一杯手冲咖啡已经彻底变凉了，然而流水线依旧在那里发出哼哧哼哧的声响，持续运转着。
吵得最凶的点特别真实。
明明只是一个很普通的、处理 CURD 的服务罢了，也不存在什么所谓的高并发黑科技，可是为何又在不知不觉当中被包装成了“重量级应用”呢？
像个出门倒个垃圾，结果背了个登山包，里头还塞了帐篷和睡袋。
这话题最近频繁被拎出来，我觉得其实和现在这该死的节奏有关。
谁偷了那十分钟？
都在追快。
功能要快要上线要快，回滚也要快。
可咱骨子里的习惯，还卡在几年前。
谈起来写Dockerfile，脑海之中的肌肉记忆即为——，“只要能够运行就可以了”。
一旦处于node:18之上的一种情况，不管三七二十一如何论，一次性毫无保留去进行npm install操作。
这事放到你我身上，一点都不陌生。
赶进度赶得昏天黑地，谁没偷过那个懒？
心里都有个小九九：先这样吧，先上线再说，以后有空再优化。
以后？
往后便是下一回构建，持续好似搬家那般，将整体家当再从头打包一回。
所谓边界感
事实上，真正存在的问题，常常并非技术方面具备多大难度，而是那些看起来似乎很平常的“默认选项”，实在是极具蛊惑性，让人难以抗拒。
默认情况下，基础镜像选择较大的那个，依赖则混合着进行装配，顺便再把构建工具留在其中当作纪念品留存下来。
很多人不是不懂区别，而是觉得“能用就行，多大点事”。
如果一旦进入了CI/CD这条流水线，那么这些看上去好像没有什么大问题的选择，全部都被放大了。
时间就是钱，耐心就这么点。
一天跑几次，情绪自然就上来了。
所以，当有人晒出，把镜像，从 2G 多，压到两百来兆，构建，从十五分钟，砍到一分多钟，大家，才会，那么，有共鸣。
并非操作有多么高端，实际上是思路发生了改变，运行环境只保留运行所需的，构建阶段的东西在使用完毕后就舍弃，这简直如同分手一般。
和生活一样，出差只带必需品，行李自然轻。
白忙活的机器
很多人担心镜像小了，万一缺工具咋办？
但现实是，真正上线跑的时候，谁他妈还在容器里编译代码？
这类讨论的话题，再三地出现，表明了一种现象，如今的工程方面的问题，越发不是关于“是否具备书写的能力”，而是在于“所书写的内容有没有那种边界的感觉”。
容器、云原生、自动化，本来是为了省事。
结果一不小心，反而成了新的负担，像请了个神像回来供着。
你说这是技术债，也对；说是习惯问题，也没跑。
只是在流水线实实在在地从二十多分钟压缩到两分钟的时候，大家才突然间狠狠地拍大腿，原来并非是机器运行得缓慢，而是我们一直以来都在致使它做了无用功，一直都在为往昔的偷懒行为付出代价。
那么回到起始的那个问题，要是你当下的项目正处于运行 CI/CD 的状态情况，你究竟是会为了图省事而依旧拖着你那个容量为两三个 G 的行李箱呢，还是会甘愿多花费半小时的时间，去把柜子再次进行整理一番，仅仅带上今晚需要换洗的衣物呢？
这种优化，在你看来是锦上添花，还是迟早要补的那一课？
我不知道答案。
我仅仅清楚，那个喝着已凉透的咖啡，眼睛盯着屏幕徒然干等的下午，我是真切地不想再度经历一回了。
Comments NOTHING