月度归档:2022年12月

我在编码过程使用Jenkins自动化的姿势

如果你是程序员新手,更推荐和建议看一下,某个角度上来说,会让你走上老手的道路。

概述

对于一般来使用自动化的团队来说,Jenkins是少不了的这个工具,使用的姿势有很多种,之前也尝试使用过多种其它的自动化工具,比如github-action/gitlab-action/Travis CI,感觉能与之匹敌的应该就github-action,其它的都可以比较专门和针对化。

使用场景

自动化能力平时用得比较多,比如最常见的IT方式,比如开发,构建,测试,运维等,基本上感觉这东西几乎无所不能的感觉。包括自己一些生活的锁事,比如电脑自动清理,某个文档的定时发布,然后做一些文档材料的定时备份,还有定时同步更新网盘,平时自己学习任务的提醒等,这东西都能成为一套东西。

总的给我的感觉是,包括自己生活也自动化起来。这里阐述从几个角度进行说明,结合自己的平常使用:

  • 生活和学习中为什么要选择一款自动化工具
  • 使用Jenkins提升自动化的操作过程

通过过程一切自动化能力,你会发现,开发人员一个人可以做项目管理中的很多事情,比如测试、运维、管理、运维、提醒等各种各样的能力。

过程阐述

目前来说,我们需要考虑时间成本和学习成本,还有管理成本,对于开发人员来说,这些是很容易做到的。

生活和学习中为什么要选择一款自动化工具

为什么要选择一款自动化工具,对于来说,节约成本,不是对公司的成本,而是对自己的成本,让自己提升更高一阶层的思考。

什么叫高一阶层的思考,比如不会再对于一些重复性的工作来来回回倒腾,不会再对以前的一些工具来来回回的倒腾,不会再对以前自己的手稿或者代码来来回回的倒腾。那其它的时间做什么的呢,主要是做架构设计的思考,新的技术点的思考,优化点的思路,这些过程从传统软件模式来说,都是成本。那我们用自动化工具做哪些事情,自己常常使用的作用是这样的:

  • 【编码】做一些练习项目工程的打包和发布,版本的发布管理;
  • 【运维】做一些常见的运维管理,还有学习示例运行,包括调用一些第三方云平台接口;
  • 【数据】做一些常见的数据抽取,汇总,统计结果管理,如每周时间段汇总;
  • 【运维】做一些自己在跑的服务检查和巡检管理,然后出现异常之后,给我报警;
  • 【测试】做一些测试用例和测试运行效果管理,类似于自动化测试之类的;
  • 【运维】做一些邮件定时清理,应用数据定时备份的管理之类的;
  • …..

编程工作中很多都需要很多,这些过程都可以变成自动化,然后自动执行,想到哪些就调用哪些,比如服务器密码修改,开始并不频繁,这个后来变成自动化,每月定时修改一次,然后自动重启服务,然后自动把新密钥发送邮箱里面,然后钉钉会告诉我这个完成了。

这些节省了我很多时间上的成本,而自己也不想在这个上面浪费太多的时间,整个过程下来你会发现,学习和生活过程中方便了很多。

当然,开始的时候可能会觉得这个怎么可能要去做那么多的东西,开始也这么思考,类似于学习Vim工具,这个开始也很难用,但是发现克服之后,你会发现工具使用效率非常高,类似于使用Markdown写文档,速度会比Word快很多,目前最多的是结合Vim+MarkDown一起使用,你会发现编写文字会是另一种享受,所以工具的使用,只是前期稍稍有一些困难,但是走下一个Demo示例之后,整个流程会顺利了很多。

对于新的开发人员来说,学习使用自动化工具,会让你方便很多,同时心理上会有一些莫名其妙的安慰感,比如你会发现很多开发人员还是手工的形式,心里面可以这么考虑,“都2023年了,怎么还是这么手工操作,效率低下。”,心里默念即可。不过对于新手来说,这的的确确增进了你很多的效率。

使用Jenkins提升自动化的操作过程

注意,以下的环境搭建是基于内网环境,注意不要暴露在公网上,我这里是在淘了一台主机回来单独放置的。

先看个简单的数据,几年沉淀下来自动化数据,目前是稍微统计的:

  • Git自动化脚本仓库有4个,自动化脚本数最多的库中有近百个脚本;
  • 积累使用的镜像容器有150个左右,包括基础镜像和学习镜像;
  • 学习安装和调试使用过的软件,在库有90+个;
  • 在过程中及当前在运行中的自动化任务有300+个;

以上自动化任务也只是管理我的学习环境,方便我自己生活中的一些自动化能力,远超我自己的想像范围。

在选择性上,老实说,自动化工具目前市面上免费的(肯定首选免费)比较强悍稳定的还比较少,我们过程需要比较高度的制定化高一些,同时会兼容很多第三方的工具和插件,这个自己相对来比较喜欢的是GithubAction,但是发现本地化和定制化能力比较强的,还是Jenkins,本地化方便放我们的隐私,而且没有约束。

那这些过程怎么做的呢,怎么实现我们自己生活和学习中的自动化呢?

准备一下脚本仓库,这里的脚本使用Git做的管理,这里选择性比较多,然后每个脚本都定时更新到Git上面,分配好目录即可,或者分配好每个Git基线的权限和职责,这个应该是比较容易做到,开始乱一些也没什么问题,后面再规范也可以。

过程方便的时候或者有灵感的时候都可以随时提交你的记录,方便后期的管理,这个基线库就会形成你后面的通用脚本库。我开始也觉得不会有多少,但是几年沉淀下来,有上百个脚本,这些都是前期学习和过程中坑点的积累,通过这些脚本库,就类似于我有一套较为完善的软件开发自动化的能力,应付一般的项目和管理完全是没啥大的问题。

比如自动化软件的安装,然后我把它放在网盘做个软件库(网盘是备份,下载使用的是七牛),沉淀几年下来的,有几十款软件,而且都是学习验证过的:

另外一个例子,在容器打包上面,平时生活中打的容器也有多个(这些只是过程中的验证,而且这些都积累成脚本),这些都是在使用过程中的坑点,一点点积累的优化完善,而且有完整的修复和优化记录,完全可以查询痕迹的,下面这些只是目录,目录下面还有多版本,包括服务器环境等。

如果你平时把自己积累的一些学习脚本还有练习脚本积累下来,两三年左右,基本上就成套了,这些规模远可能超过你原来的想像的。

所以这些自动化的脚本基本上都我都打成一套脚本放在Git管理,同时不断的优化完善,然后通过Jenkins的自动执行操作,而整个下来的Jenkins任务下来,到目前为止,也有300多个自动化任务,这些只是我一个人在过程中的自动化操作任务。

在集成脚本管理之后,各类型的定时化管理,比如一些可能需要调用的第三接口,如果比如集中的,这里采用Python脚本或者Java脚本进行编写,一些简单的脚本编写并不难,只是简单的调用,然后集成自动化发布和版本更新管理,这样在任务里面就可以调用这些脚本。

这类似的场景并不是特别多,也考虑过做成Jenkins插件,但是感觉没啥必要,维护这个插件成本也不低,另外兼容性等成问题。

有了脚本库还有定时化解决之后,任务的排版目前使用是Jenkinsfile,即Pipeline进行任务编排,这个方式效果会好很多,至少在打包上,几乎可以做到一种无所不能的感觉(当前,你也可以理解成它就是一个执行器),但是整合起来效果就非常强大。

不过就是工作流的执行上,当前比较差强人意,目前Jenkins的编排还是硬编码的形式,还不能有可视化拖拉,多个任务形成原子性,不过基本上也可以达到效果,就是简单的流程还行,多个复杂的流程就有点难,整体下来结合使用的效果还是不错的。

这些任务常年累月下来,形成的自动化能力基本上已经覆盖了平时编码和学习的场景,节省了我很多的时间和场景。同时自己也在不断的优化找更好的方案提升本身学习环境的效能,目前使用的方式都是有现成的脚本案例参考还有调优模式,然后不断的优化查找更好的方案,尝试使用过其它的自动化工具,但是还是缺少很多的能力和稳定性。

这些对于开发人员特别是新人来说,相对来说,会节约很多的时间成本和学习沉淀,不管是在后期工作中还是管理中,自动化的能力都是很普遍的,比如对于中小型公司来说,这基本上整体的效能会提升很多,对于个人来说,积累下来的东西是在某个程度上,也是经验的积累,在一些工作上是远远超过资历年限的积累的,修改一下就可以使用,会解决很多问题。

总结

自动化能力在IT领域是普遍的能力,工具的使用和场景的覆盖面,还有效能的提升相对来说对个人是一个非常大的帮助,也见过很多在使用自动化能力的,在很多场景下是可以优化的,同时提高效率的。

以上是自己使用Jenkins自动化操作的一些场景和经验积累,提供做下参考。

我从0到1开发一款软件产品的心得总结

致敬那些可以保持初衷的软件开发者,推动国内软件发展的开源社区者,这也是自己的愿景和努力方向,在这个过程中追求和寻找软件技术的乐趣。

这里不提项目和软件的名称,只考虑总结心得。

背景

目前最多的技术依然还是从国外传入,国内的更多是的翻译还有培训传播,国内的基础软件并不是很发达,还有很多进步的空间,自己接触的软件这十年并不长,见到现状有改变,在追赶,过程是不断的突出和展现类似于阿里、百度、腾讯等这些对国内社区产生影响力的产品,同时很多优秀的开源项目,推动国内软件的进步,这些是值得尊重和致敬的。

自己原来的初衷也是把过程的一些研究成果贡献和体现,在这个行业中,以自己的一些经验,给一些团队或者个人提供参考经验,同时可以和国内知名的技术团队或者个人进一步的交流沟通,自我提升,这是开始的初衷。过程也困难很大,而对于自己来说,前期最大的是能让自己的设计理念活下去,不烂尾,不间断,可持续,这是一个过程的完整体现。同时,自己提供了完整的手稿和设计思路开源,希望可以给这块做设计的人员一些参考。

概述

对于软件产品来说,自己开始遇到的概念更多的是项目,或者开发技术,并不是理解一个产品的概念,同时对产品经理或者设计的角色理解比较片面,并不是真正一款产品本身的意义,也是在这个过程中,不断的加深理解,不断的学习。

针对于当前社区的产品,真正的来说,推动行业的进步和发展,解决过程的很多的痛点(这里指的是软件产品),比如Nexus解决了包的问题,Docker解决了容器化管理的问题,Hadoop解决了企业落地大数据的问题等等这些,Jenkins解决团队DevOps的问题等,推动软件行业的进步,同时这些都是国外的社区产品,国内也有类似于Skywalking、Kubeshpere等。自己本身是软件工程专业,对这块的痛点和进步,是更多的理解和体会。

后来发现,每一款产品的背后,都是一个团队很大的付出和努力,过程更多的也需要承受很多的未知挑战,怎么让产品能活下去,而不是变成烂尾,持续输出应该有的能力,类似于ElementUI在前段时间没有维护,很多人也是觉得可惜,以前Dubbo在国内是服务化的代表,各种方面都不比Cloud差,但是前几年突然停止维护,很让人可惜,如果能持续进社区发展,可能Cloud就很难切入,开始也觉得奇怪,但是自己在做的过程发现,要真的去维护一个产品,需要消耗很大的精力,特别是在前期没有任何收益的情况下,能支持下来真的很难,在跟挺多开源项目的作者聊,往往下班或者业余的时候都是排得满的,这里也是致敬国内社区的开发者。

这里阐述从开始社区的开源产品说起,这个过程是怎么建立项目,然后再到新版本闭源,再到商业化,再到目前可以持续输出我们可以输出的产品设计稿一些心得总结:

  • 基于一些方法论的自我探索和产品型规划
  • 开源到商业化的转变,团队运营和促进可持续性
  • 团队后期一些坚持的理念和一些初衷还有输出

从以上几个点进行一产品建设总结,我有我思,以供参考。

过程

过程并不是特别顺利,会遇到很多的问题,也会遇到很多困难,还有很多失误,但是从18年到现在,欣慰的大家还是可以现在,并且还在发力发展期。

基于一些方法论的自我探索和产品型规划

建设产品型软件的思路来自于服务化的一些困难,同时方案查找,发现缺少的挺多,而基于很多企业还有项目的限制,同时也包括自身的限制,进行了产品的定位,把自己的一些经验通过文档和编码和形式进行沉淀和输出,期望可以和同行进行更多的交流,同时也想促进自己的进步。

进行了整体的从产品的方向,架构,技术,编码,前后端,运维,测试,自动化等等进行了一系统的规划,基本上第1年的时候,

这个时间通过结识是一些对软件有兴趣的人,包括一些社区的人员,整体聚合起来的人,都以兴趣为主,本身就是编码出身,开始并不喜欢接触一些商业化的内容,通过前期的容器化还有服务化,同时各类Ops的研究,结合自己本身的经验进行的产品化架构。开始产品化的思维并不是从一开始就存在,而是以前的项目经验和编码中,对自己的一些经验总结和案例总结,包括大学时期的一些经验总结,重复性的编码确实消耗了很多时间,组件化和产品化的能力,会节省很多的时间,不需要重复的建设,这些基本上都是传统项目的痛点。

在本身工作后不断的提升,不想把时间消耗在基础能力的建设上(类似于发布很麻烦),当时在找了很多方案之后,在社区上找不到合适的,另外就是方法论较多,缺少实践的过程和能力,类似于中台、微服务、数据治理等,很多偏向于表面层,网上的资料偏向于demo整合或者一半一半的,没有完整的体系(现在应该比较成熟了)。

基于以上,只能基于各类开源项目还有自身的经验,进行的产品化的建设。

开源到商业化的转变,团队运营和促进可持续性

在前期建设的一年多,手稿和形态基本上已经形成一稿,同时也会发现很多的问题。

一个最明显的问题,可持续性,后来发现,很多开源项目同样面对此类似的问题,可持续性来说,对于一些来说,可能是一阵热风,这个时候兴起某个技术,就会去做这个,然后过了之后,这个就没有了,或者放弃维护,自己同样也面临这个问题。

当然,自己本身来说,并不是特别期望的商业化运作,直白一点的,这个只是业余的经验总结输出和研究,开始并没有需要一定是需要商业化,更多的是经验的分享和社区的交流目的,自己本身的生存收益并不是来源于这块,同时也并没有说这块特别困难。

后来发现,其实坚持做一件事情的,而且能持续的投入的人员是很难的,很多可能面临生活,工作等问题,久了很快最后提交代码的,就只有我这边,社区的会议也减少到几乎没有。在不断的寻找他人一起互相分享学习的时候,基本上都是被冷脸或者闭门的,本身会不断的发展和提升产品的成熟度,过程中接触的人群也普遍不同,但是这个找兴趣团队的过程,确实很难,培养他人起来也很难,一个人孤军会存在莫大的孤独感,大半夜往往也只有你一个,后期也有很多人兴趣的朋友加群加微信讨论,大家没有前期的基础,也很难跟上,基于项目的不断完善,进步过程还需要接触很多架构和思维。

这个状态持续了近大半年,发现这样对原来的产品化和发展形成极大的影响,是在维护,但是这并不是一个健康的发展状态和维护状态。

这个过程意外的是,免费分享的很多并不太喜欢,但是需要商业化支持的却有挺多的,常常会收到一些社区或者厂家的联系,进一步的商业化支持的倒是挺多的(即投资),开始是拒绝的。因为我并不想拉扯上太多的关系,简简单单的互相分享,业余时间的沟通感觉会更好,后来发现,这个太难了。基于上面的情况,自己也不得不反思如何后期如何做这个项目。

在看到其它的开源类项目,为什么可以做到,也想学习,不断参考,后面明白,你并不是那个项目的负责人,你也不是他,每个的条件和环境是不一样的,不能说别人做了淘宝,你也复制他的模式也会成为淘宝,你很难跟得上,需要考虑另一个模式,比如拼多多模式。考虑到项目的持续性和可用性,在跟多家团队负责人商谈后,不断磨合,考虑良久,进行了商业化改变,通过投入人员和项目,进一步的促进项目的可持续性和成熟。

再进一步的产品化能力和团队运营管理。

团队后期一些坚持的理念和一些初衷还有输出

在后期建设的过程,自己要承担的角色和责任可能会有一些变动,但是推动产品化的进程是加速了很多,从0.0.1版本不断的提升到2.1.3版本,不断的跟进当前行业的发展和技术整合,也是做了很多的调整和升级,当然,也做了很多的减法。

与运营团队的配合操作,有一些是远超过我的想像之外的,也消耗了大量的精力,后面有一段时间全身心的投入到里面,开始有考虑过这个过程,也有一定的预期心理准备,同时也需要做很多方面的管理,当然,本身也提升了很多,产品化和项目化也基本上符合预期实现,在这个过程中遇到的问题点,团队的成长还有产品的成熟都基本上能达到预期效果,而且后面维护可以做到保障,这个是自己特别关注的。

在接触的过程中,这几年,也遇到很多中小团队在做类似的内部项目,可能更偏向于内部,这些也是原来的自己想做的经验分享,在当前的网络环境上,也已经有很商业的化的产品,同时也提供了很多方案,但是全套型的依然很少,即从0到1的过程还有最终的效果。

当前在各个方面较为稳定的情况下之后,针对于自己的初衷,考虑左右,梳理了很多过程中的手稿内容,同时梳理了很多过程中手稿,包括产品化设计、架构、思路等,进行输出,希望可以给一些建设过程中的团队一些参考意见,规避过程中的一些坑点,有个方向参考,即从政策、产品、团队、管理、方案、架构、自动化等形成的一套参考方案,当然,每个团队不一样,但是有方向就会规避掉很多的迷茫点,至少会快很多,毕竟这些积累了很多年的架构经验和项目实践经验。

这些是我所带团队能对自己原来初衷的保持和最大化方式,毕竟在涉及到多方之后,你需要考虑很多很多。

收尾

在建设过程中,会遇到很多问题,同时看到国内技术社区的推动,国内社区产生影响力的产品,同时很多优秀的开源项目越来越多,提交到apache的项目也越来越多,推动国内软件的进步,这些是值得尊重和致敬的。

也许在这个过程中,本身并没有达到他们的层面,但是在本身的经验里面,可以做出一定的分享,这是个人能做的。

以上为从零建设软件产品的一些心得总结,以供自我复盘和勉励。