每到周五delivery的时候，就是体现我是一个苦逼的IT民工的时候。如果幸得春哥曾哥庇佑，一切顺利的话，只需要跑跑自动化脚本就好了，这倒没有什么令人抓狂的，因为一切都是按照理想状态发展的。即便有时候被硬件平台block住，也是短暂时间可以解决的，即使查不到原因，重启一下平台也就搞定了。最苦逼的莫过于硬件平台莫名其妙的挂掉了，自动化脚本莫名其妙的终止了。不幸的是上周五就被我遇上了，幸运的是我该考虑改进这个“拿来即用”的脚本了…
一般周五中午我们team的rpm就发出来了，然后我要开始MT，理想状态下一个小时左右就搞定了。然后deliver给PF team，PF team开始做CD2-MXPF-
先说说PF team做iso和BT的自动化脚本，嗯，在理想状态下，那是很爽的，跑上脚本，然后等着邮件就可以了。以前我遇到的问题很容易就可以搞定：undo checkout然后重新跑一下，或者因为平台问题要手动跑一下BT。而周五遇到的问题让我严重怀疑这个脚本的鲁棒性。
周五做完MT就下班回家了，到家后开始做delivery (我太敬业了~)。有句话怎么说来着：要么不发生，要么接踵而至。跑deliver脚本出现了ISO create failed，无法生成iso文件，从最近的log可以看出是ClearCase找不到要check out的文件，但是我查看一下这些文件是存在的，这不是直接问题。在往上查看log，发现某些在共用区域 (如/tmp/下) 创建的文件操作permission deny了，ps查看了一下进程，当前没有用户执行相同脚本。查看了一下我们普通用户创建的文件权限是644，也就是说无法修改他人创建的文件，ls发现这些文件是xq同学创建的，fuck，肯定是中途中断脚本导致文件没有自动删除，而后也没有手动清理掉。果断su到xq账户，删除这些tmp文件。
又跑了一下脚本，发现还有一些/tmp/下的文件没有操作权限，该文件是bd同学创建的，最后修改于20分钟前，问bd同学，他说一直在玩游戏，没有做任何操作，fuck，这是哪位无良同学用别人账户玩，再次删除之。
再跑脚本发现还是有问题，得到的上一个版本的label是S标的，fuck，S标签只用于branch上，哪位同学给搞到main分支上了，修改脚本，手动设定成最近的一个P标签的label。
然后再运行之，还是ISO create failed，查看log发现check rpm file失败了，找不到上一个version的CD2 的文件，在delivernote.lst里的文件名和存放iso文件isoimg文件夹下的文件对应不起来，查看了一下isoimg文件件下的最近修改时间，是今天中午11点26分生成的，fuck，又是哪位无良同学，运行脚本之前不先config，导致覆盖掉了上一个version的文件。
我手动设定上一个version的CD2的前一个label，试图再次生成上一个version的CD2文件，可能由于脚本的问题，生成的文件版本和delivernote.lst里的文件名对应不起来，试了几次，总有些文件对应不起来，最后忽然想到可以从iso拷贝出所有的rpm覆盖掉isoimg下的文件，然后再删掉不相关的文件，才搞定这事。
再次执行，God bless me，终于成功了。从晚上7点钟到凌晨2点钟，我手动做做两遍都能做完了。我只想说，在一些不管三七二十一随便乱用的同学的蹂躏下，这个脚本显得多么的脆弱，脆弱到自动化成了最大的诟病。
在愤怒前面一些同学的肆意妄为时，也促使我思考自动化脚本要注意些什么。
- 像其他程序一样，强烈要求最小模块化，这样做可以使脚本更容易定制，通过参数设置可以很容易做到只生成iso而不做BT，这是目前的脚本做不到的 (只是说太弱了~) 。
2.模块化的另一目的就是步步为营，要考虑到每个模块出错时的行为，而不是到最后报一个error，导致看似莫名其妙的错误。当某一模块出错时，前面的所有模块是否需要回退。
3.充分考虑多进程情况下的问题，同一用户只能运行一个进程实例，不同用户间共用文件，给共用文件设置正确的权限，如同组用户可以修改；也可以创建不同的文件以消除竞争，比如文件名包含用户名，这样每个用户的文件都是独立的，即使在共用目录下。
3.再自动的脚本也不是完美的，强烈要求出个memo，或者给使用者培训一下，避免让人想骂SB的不正常错误出现。
暂时想到这么多，以后遇到其他情况随时补充。
