锁文件该不该进仓库，换台机器构建对不对得先看它
同一份代码，在开发自己那台机器上跑得好好的，换到构建机上就报一处找不到方法。两边对照了半天，代码一模一样，末了发现差在一个不起眼的文件上：一台记着上次实际取到的版本，另一台是当天现去仓库里取的。一、先认清锁定文件记的是什么
它记的不是打算用哪个范围，而是上一回真正取回来的那一整套：每个库、每个捎带来的底层件，各是哪个版本、从哪儿取的。有它在，换台机器照着念就能还原出同一套东西，不用碰运气。
也正因为记的是实取结果，它跟手写的范围表是两回事。范围表说可以要这一档里的任意一份，锁定文件说上回拿的是这一份。两份各管一头，谁也替代不了谁，别只留一份就以为齐了。试一轮要占多少工时，排的时候先算进去，别把它当成顺手就能做的零碎，到了那天两头都要人，哪头都凑不齐。
二、应用类的活儿该把它交进仓库
要交付出去跑的东西，锁文件跟着代码一起交，构建机照着它取，打出来的和本地试过的就是对得上的同一套。哪天线上出了状况，想复现当时的情形，翻到那一版的代码也就翻到了那一版的依赖。
不交进去，等于每次构建都重新抽一次签。仓库里某个库刚推了新版，明明自己一行没改，产物却悄悄变了，查起来格外费劲：改动记录里干干净净，问题却实实在在冒了出来。拿哪几台机器走这一轮，提前跟管机器的人约好，临时开口常常碰上别组也在用，等来等去把半天耗过去了。
三、供别人引的库要另说
写给别人用的库，交上去的锁定文件往往只管自己开发时那一套，引它的人未必照这个来。这时候更该花力气的是把版本范围写得老实些，别把还没验证过的档位也圈进去。
这类库可以在自己这边留一份锁文件给回归用，但别指望它替下游做决定。范围写窄了下游没法并，写宽了自己又没试过，两头都为难；折中的办法是多试几档常见组合，把试过的写进说明里。对照的那份结果存在哪儿，写在单子头一行，找的人想的是升之前那一版，不是文件夹按日期排出来的名字。
四、改锁文件要单独看成一件事
升级一个库，范围表可能只动一行，锁文件却跟着翻出十几行：捎带来的底层件全被带着换了一轮。这种改动别混在一堆业务代码里一起交，单独放一笔，看的人才能明白这回动的只是依赖。
复核时重点看多出来的那几行，有没有哪个底层件被顶到了从没试过的版本。范围表上看着只升了一格，实际连带换掉一串，这种情形并不少见；单放一笔，正好逼着人多看这一眼。谁盯数、谁记结论分清楚，一个人两头顾，容易把看了一半的数当成看完了，回头还得再拉一遍。
五、构建机别偷偷现取
构建脚本里若留着一句先更新再装，锁文件就等于白交了：脚本会把记好的版本又抹掉，重新去仓库里拿新的。要复现，就得让构建老老实实按锁文件来，更新只在有意升级的那一回手动做。
缓存也得跟着管。构建机常把下载过的库存起来省时间，缓存里若混着一份旧的同名件，取出来的未必是锁文件写的那份。隔一阵清一次，或者干脆按锁文件内容给缓存分档，别让省下的那点时间换来一次说不清的偏差。边界那几档要不要单独跑，会上先定个说法，别等收工时才有人想起来，那时候机器都还了，再借又是一轮。
六、对不对拿两台机器比一回
挑两台干净机器，各自从头构建，把两边产物里依赖那一层列出来并排比。清单一致，才算这套办法真立住了；有一处对不上，顺着差的那行往回找，多半就是某个环节还在现取。
比过的结果留一份，连同当时的锁文件一起存着。往后有人问换台机器到底稳不稳，不用再讲一遍道理，把两份清单摆出来就行；真出了偏差，也有个现成的样子能对照着看是哪一步走了样。
换台机器就出岔子，很少是代码挑机器，多半是依赖那一层没被记死。认清锁文件、交进仓库、按库的类型分别对待、单独复核改动、管住构建脚本、两台机器比一回，六件事顺着做，产物才谈得上对得上；少了哪件，都容易变成一句在我这儿是好的。 感谢楼主愿意花时间分享，让我们这些后来者能少踩很多坑。 经验很宝贵，尤其是亲身实践过的总结，比网上随便找的靠谱多了。
页:
[1]