自动化所有可以自动化的无聊事物,也许应该自动化.
其他人是否知道这种自动化,取决于它的价值,而不是看繁忙。
照片由放大器显示 过去几个月我一直在上班的路上 ——我们建设过程的自动化。
我学到了很多关于Jenkins如何工作, GitHub, Jenkins, Artifactory, Docker, Ansible 等之间如何互动。
我开始缓慢,一个建造管道 来创造和推动多克的图像, 我继续增加管道,因为我觉得需要。
今天,我有一套管道 运行测试,密码覆盖, 建造,部署,清理, 运行安全扫描 通过x86和S390x。
这个套房的一些亮点 - 一个多架构建筑 - UI建于一个x86代理上并构建文件夹发送到一个 s390x代理上.
此代理随后构建后端和最终图像 An 端到端.jar 更新器 - 分离java寄存器,其.jar 文件被导入到要调用的主寄存器中.
管道建造了这些.jars,并在GitHub上自动创建了PR.
这为我和我的团队腾出了很多时间 也帮助系统(和我)保持正常, 我不停地寻找我现在可以自动化的东西, 特别是小而平庸的任务, 因为节省的时间真的增加了。
任何人读到这个,或未来我, “自动就像定期运动;你可能看不到立即的结果, 但以后你的系统会感谢你。” 含糊不清 其中最大的阻断者往往是几年前在Magnific A上星线对同一种词的理解上的区别, 当我刚开始做软件工程师时, 我挣扎着模糊不清。
在此之前,要求是直接的任务,大部分都写下来。
现在,我认为,处理模棱两可的问题和通过它进行筛选,是我的大部分工作。
有多个利益相关者,范围从技术到非技术规模——产品,UX,领跑,CS;都具有广泛的意见和专长领域.
特别是在今天,由于编码助理是如何工作的,我认为,即使在第一次输入时,也必须查明和解决模糊之处。
我个人发现在这样减少生成的代码(噪声)数量方面,取得了更大的成功.
我所听到的每个大故事,现在总是以同样的方式开始——看看总结,接受标准和描述,注意我读这些东西时想到的问题.
找出谁是最好的人 问这些问题,并接触他们。
编辑票本身以反映我得到的答案.
只有在1 -3步骤之后,我才开始做任何改变。
我只能体验Scrum, 也许其他类型的Agile可能会解决其中一些问题, 也可能不会解决, 我不知道。
提出Agile是为了解决瀑布问题。
意图是快速移动和打破东西。
敏捷性是必需的,特别是在今天的快动世界中,而"敏捷"背后的理论一直推动赋予团队独立运行的能力.
但实际上,我对它有些问题。 1) 估计问题 - 故事点:"将一个随机数字指定给一个你或别人以前从未完成过的任务,这样我们就可以知道它有多困难,需要多少努力".
对于给定的罚单来说,对于一个以前在类似问题上工作过的人对一个没有工作过的人来说,故事如何是相同的?
当一个低年级学生从未见过这个密码库时, 我们如何把故事点配成一个时间单位(印刷品),却声称它们与完成任务所需的时间无关? 2)责任问题 - 范围爬行:神奇地激动起来