部署也是工程的一部分,也要编程(自动化)
部署和开发一样,同样面临变化。同样有复杂的细节。
同样应该代码化,自动化。把复杂性、思路,操作,都固化下来,显式表达。
不要“雪花”式配置。
把最近看的文章摘抄一下 集句:
1频繁做让你感到痛苦的事情:小步快走,分散痛苦与风险 《持续交付的实践与思考》
2将复杂的构建流程纳入一个简单的脚本文件,然后用一条命令调用。《流水线即代码》
(凡是可以被编码的东西都已经被代码化了。《流水线即代码》
为软件发布创建一个可重复且可靠的过程、将几乎所有的事情自动化, 把所有的东西纳入版本控制《持续交付的实践与思考》
)3 『Done』意味着『已发布』:没有完成百分之多少这种说法《持续交付的实践与思考》
4工程师文化是自由+效率,在自由的环境下对提高效率的痴迷,就一定会发生创新。《什么是工程师文化?》
5 把懂简化和喜欢自动化的人招进来,然后在绩效考核和升职的地方设置上一条硬性指标——你今年简化了什么?自动化了什么?《什么是工程师文化?》
自己的切身体会:
对于1,其实这是反人类的方式(趋乐避苦)。频繁做痛苦的事而不是爽的事。
不但不避苦,反而还要频繁,反复多吃N多苦,然后才能把痛苦分散和化解。(和《反脆弱》里说的释放金融风险,要多次小崩溃才能避免1次大崩溃,军事上也是一样,其实是同样的道理。)
这几天用docker部署taiga的过程,回头看,其实是把痛苦的安装操作系统,配环境自动化,然后多次重复,1天重装系统几十次、上百次的过程。
只不过每次都是用1行命令而已,
体会到了痛苦,才知道什么最有价值。回过头看之前的自己,确实感觉到了“功力向前进,功效向后看”。
2 部署本身也是个软件工程,也有需求(交互步骤),也是要写代码的。
3 还有欠缺
4 5 我还是做到了,去年到今年在简化的道路上功力大进了。
1用《软件方法》和EA简化了需求到分析到出文档的大量工作。
2用版本控制和docker 简化了开发工作 配环境,拉代码
——未来需要研究一下CI/CD,把测试、发布搞起来
—— 继续简化产品使用。