部署也是工程的一部分，也要编程（自动化）

部署和开发一样，同样面临变化。同样有复杂的细节。

同样应该代码化，自动化。把复杂性、思路，操作，都固化下来，显式表达。

不要“雪花”式配置。

 

把最近看的文章摘抄一下 集句：

1频繁做让你感到痛苦的事情：小步快走，分散痛苦与风险 《持续交付的实践与思考》

 

 

2将复杂的构建流程纳入一个简单的脚本文件，然后用一条命令调用。《流水线即代码》

（凡是可以被编码的东西都已经被代码化了。《流水线即代码》

  为软件发布创建一个可重复且可靠的过程、将几乎所有的事情自动化， 把所有的东西纳入版本控制《持续交付的实践与思考》
）

3 『Done』意味着『已发布』：没有完成百分之多少这种说法《持续交付的实践与思考》

 

4工程师文化是自由+效率，在自由的环境下对提高效率的痴迷，就一定会发生创新。《什么是工程师文化？》

 

5 把懂简化和喜欢自动化的人招进来，然后在绩效考核和升职的地方设置上一条硬性指标——你今年简化了什么？自动化了什么？《什么是工程师文化？》

自己的切身体会：

对于1，其实这是反人类的方式（趋乐避苦）。频繁做痛苦的事而不是爽的事。

不但不避苦，反而还要频繁，反复多吃N多苦，然后才能把痛苦分散和化解。（和《反脆弱》里说的释放金融风险，要多次小崩溃才能避免1次大崩溃，军事上也是一样，其实是同样的道理。）

这几天用docker部署taiga的过程，回头看，其实是把痛苦的安装操作系统，配环境自动化，然后多次重复，1天重装系统几十次、上百次的过程。

只不过每次都是用1行命令而已，
体会到了痛苦，才知道什么最有价值。回过头看之前的自己，确实感觉到了“功力向前进，功效向后看”。

 

2 部署本身也是个软件工程，也有需求（交互步骤），也是要写代码的。

 

3 还有欠缺

 

4 5 我还是做到了，去年到今年在简化的道路上功力大进了。

　　1用《软件方法》和EA简化了需求到分析到出文档的大量工作。

       2用版本控制和docker 简化了开发工作 配环境，拉代码

   

——未来需要研究一下CI/CD，把测试、发布搞起来

—— 继续简化产品使用。