Commit Check 的最新更新 —— 新增检查 pull request 是否已经 rebase(WIP)

背景

最新有用户提出来(issue 191)是否可以让 commit-check 支持对于对分支进行是否已经 rebase 检查,跟其他检查一样,可以支持开启或是关闭。

哼哼,感觉这是一个不错的建议。因此经过一周过的晚上下班的陪娃间隙的时间的努力,现在正式宣布在最新的 commit-check 以及 commit-check-action 中都已经支持了一个新的选项叫做 merge-base

对了如果你还不知道什么是 commit-check,这里我要隆重的介绍以下:

Commit Check 是一个免费且强大的工具,用于强制执行提交元数据标准,包括提交消息、分支命名、提交者姓名/邮箱以及提交签名,变基。它的错误信息和建议命令都可以完全自定义,确保团队之间的一致性。

作为 GitHub Enterprise 元数据限制和 Bitbucket 付费插件 Yet Another Commit Checker 的替代方案,Commit Check 通过集成 DevOps 原则和基础设施即代码(IaC)脱颖而出。

那么如何使用 commit-check 呢?有以下几种方式。

配置

使用默认配置

如果你没有设置 .commit-check.yml,Commit Check 将使用默认配置。提交消息将遵循 Conventional Commits 规则,分支命名遵循 Conventional Branch 规则。


转载本站文章请注明作者和出处,请勿用于任何商业用途。欢迎关注公众号「DevOps攻城狮」

从早到晚,我的 DevOps 一天

很多人可能会好奇,作为一名 DevOps 工程师,每天究竟忙些什么呢?今天就来简单聊聊,作为 DevOps/Build/Release 工程师,我的日常工作节奏是怎样的。

工作准备

每天早上九点半到公司,第一件事就是打开 Slack 和邮箱,优先处理那些紧急或容易回复的消息。遇到比较复杂的内容,就会设置提醒,以防漏掉。之后,会把当天的任务列入 To-Do List,再检查 Jenkins 上是否有失败的任务需要关注。这一系列动作大概会花半小时左右。

咖啡时间

十点左右是咖啡时间——一天的正式开始。如果十点半有站会,那就是一个快速的回顾和计划环节,主要是分享昨天的进展、当天的任务安排,也和团队同步一下各自的状态。

日常工作

开始工作后,我会打开 VSCode,接着前一天没完成的任务。平时常用的代码仓库包括 pipeline-libraryansible-playbookdocker-imagesinfra,它们分别负责管理流水线、自动化脚本、容器和基础设施。几乎每天都会对这些仓库进行一些更新或优化。

Build 和 Release 也是我的主要工作之一。构建任务已经实现了自动化,团队成员通过 Multibranch Pipeline 自行构建;我主要负责分支管理、发布时的合并和冲突解决,确保发布信息的准确和版本的合规性。

此外,还有一些日常任务,比如:

  • 维护和升级构建环境
  • 收集代码覆盖率,生成报告
  • 升级编译器,处理相关问题
  • 管理虚拟机分配,帮团队解决环境问题

上午的主要工作还是消息回复和问题处理,之后再逐一处理 To-Do List。

午餐与休息

中午十二点半左右和同事一起午餐。吃饭时聊聊天,也是练习英语的机会。饭后,有时会和同事一起在附近散步,或者自己跑步运动一下。

下午

下午是主要的产出时间。从一点半到四点半,专心处理 To-Do List 上的任务,尽量推进工作进度。四点半之后,美国同事上线,可能会有会议或讨论需求。

晚间时光

晚上是家人时间。天气渐冷,不方便带孩子出门散步,我们偶尔会去超市采购。如果孩子自己看书或看动画片,我会利用时间给开源社区做点贡献,或是写文章。

这就是我在 DevOps 岗位上的一天,一边忙工作,一边兼顾家庭和爱好。希望这个小分享能让大家更了解这个岗位的日常。

​你更喜欢我分享一些技术,还是更偏爱这种工作、生活的日常?欢迎留言告诉我!


转载本站文章请注明作者和出处,请勿用于任何商业用途。欢迎关注公众号「DevOps攻城狮」

What Optimizations I Made During the Jenkins Upgrade

Background

Recently, I’ve been working on migrating and upgrading Jenkins. The main motivation is the vulnerability CVE-2024-23897.

Jenkins 2.441 and earlier, LTS 2.426.2 and earlier does not disable a feature of its CLI command parser that replaces an ‘@’ character followed by a file path in an argument with the file’s contents, allowing unauthenticated attackers to read arbitrary files on the Jenkins controller file system.

To address this, Jenkins needs to be upgraded to at least version 2.442 or LTS 2.426.3 or above. This was also an opportunity to rework parts of the setup that weren’t initially optimized.

Pre-Upgrade Jenkins

Before the upgrade, we were using Jenkins 2.346.3, the last version supporting Java 8. Because older operating systems don’t support Java 17, this blocked us from upgrading Jenkins.

That said, our initial setup was already well-structured:

  • We followed the Infrastructure as Code principle, deploying Jenkins through Docker Compose.
  • We adhered to the Configuration as Code principle, managing all Jenkins Pipelines with a Jenkins Shared Library.
  • We used Jenkins Multibranch Pipeline to build and test projects.

However, there were some limitations, such as:

  • The Jenkins server didn’t have a fixed domain name like jenkinsci.organization.com, but instead had a format like http://234.345.999:8080. Whenever the IP or hostname changed, Webhook configurations for this Jenkins instance had to be updated manually in the Git repository.
  • We hadn’t adopted Docker Cloud. While many tasks used Docker for builds, we weren’t utilizing Docker JNLP agents to create dynamic agents for builds that would automatically be destroyed upon completion.
  • The naming and code structure of the Jenkins Shared Library needed refactoring, as it was initially created for a single team, which limited repository naming.
  • We hadn’t yet used Windows Docker Containers.
  • Some Jenkins plugins were likely outdated or unused but still present.
  • Jenkins and its plugins weren’t regularly updated due to the Jenkins Agent version restrictions.

Post-Upgrade Jenkins

Building on prior best practices, we made the following improvements:

  • Continued following the Infrastructure as Code principle, and using Nginx as a reverse proxy, we deployed Jenkins with Docker Compose to ensure a stable domain name.
  • Continued to follow the Configuration as Code principle.
  • Continued using Jenkins Multibranch Pipeline for building and testing projects.
  • Where possible, implemented Docker Cloud for builds.
  • Renamed the Jenkins Shared Library to pipeline-library (aligning with Jenkins’ naming conventions) and refactored many Jenkinsfiles and Groovy files.
  • Introduced Windows Docker Containers to build Windows components.
  • Utilized the Jenkins Configuration as Code plugin and scheduled regular configuration backups.
  • Installed only necessary Jenkins plugins and exported the current plugin list using the plugin command.
  • Attempted to automate plugin backups before upgrading, enabling quick rollback if the upgrade fails.

Summary

I hope these efforts enable Infrastructure maintenance and Pipeline development to be managed through GitOps.

Through continuous exploration, experimentation, and application of best practices, I aim to establish CI/CD as a healthy, sustainable, self-improving DevOps system.

从 Jenkins 升级,我做了哪些优化

背景

我最近在做的一件事情是迁移并升级 Jenkins。主要动机是因为这个漏洞 CVE-2024-23897

Jenkins 2.441 及更早版本、LTS 2.426.2 及更早版本未禁用其 CLI 命令解析器的一项功能,该功能会将参数中文件路径后的“@”字符替换为文件内容,从而允许未经身份验证的攻击者读取 Jenkins 控制器文件系统上的任意文件。

因此需要将 Jenkins 至少升级到 2.442 或 LTS 2.426.3 及以上版本,也趁此机会重新重构之前没有做满意的部分。

升级之前的 Jenkins

升级之前我们使用的是 Jenkins 2.346.3,这是最后一个支持 Java 8 的版本。由于老的操作系统不支持 Java 17,导致无法升级 Jenkins。

实际上,在升级之前我们已经做得还不错:

  • 遵循了 Infrastructure as Code 原则,我们通过 Docker Compose 部署 Jenkins。
  • 遵循了 Configuration as Code 原则,使用 Jenkins Shared Library 来管理所有的 Jenkins Pipeline。
  • 使用 Jenkins Multibranch Pipeline 来构建和测试项目。

但也存在一些不足之处,比如:

  • Jenkins 服务器没有一个固定的域名,比如 jenkinsci.organization.com,而是 http://234.345.999:8080 这样的格式。所有配置到这台 Jenkins 上的 Webhook 当 IP 或 hostname 变化时,需要从 Git 仓库同时修改。
  • 没有使用 Docker Cloud,虽然很多任务已经使用 Docker 构建,但没有使用 Docker JNLP,也就是动态创建 Agent 来进行构建,完成后自动销毁。
  • Jenkins Shared Library 的名字和代码结构需要重构。当初创建时只是为一个团队而做,因此仓库名字比较受限。
  • 没有使用 Windows Docker Container。
  • 有的 Jenkins 插件可能已经不再使用,但仍然存在。
  • 由于 Jenkins Agent 版本的限制,Jenkins 和插件没有及时更新。

升级后的 Jenkins

在保留了之前好的实践的基础上,我们进行了以下优化:

  • 继续遵循 Infrastructure as Code 原则,同时通过 Nginx 作为代理,使用 Docker Compose 与 Jenkins 一起部署,确保拥有一个固定的域名。
  • 继续遵循 Configuration as Code 原则。
  • 继续使用 Jenkins Multibranch Pipeline 来构建和测试项目。
  • 尽可能使用 Docker Cloud 来构建。
  • 将 Jenkins Shared Library 重命名为 pipeline-library(与 Jenkins 官方命名一致),并对大量 Jenkinsfile 和 Groovy 文件进行了重构。
  • 引入 Windows Docker Container 构建 Windows 部分。
  • 使用 Jenkins Configuration as Code 插件,定期备份配置。
  • 仅安装必要的 Jenkins 插件,并通过 plugin 命令导出当前的插件列表。
  • 尝试在升级前自动备份插件,确保升级失败时能够快速回滚。

总结

我希望通过这些努力,将 Infrastructure 的维护和 Pipeline 的开发通过 GitOps 方式进行管理。

不断探索、尝试和应用最佳实践,使 CI/CD 成为一个健康的、可持续维护的、自我改进和成长的 DevOps 系统。


转载本站文章请注明作者和出处,请勿用于任何商业用途。欢迎关注公众号「DevOps攻城狮」

选择往往比努力更重要

偶尔深夜躺下时,我常常在想,我是怎么就走到这了?这都是源于毕业后的一系列选择吧!

也时常感慨,选择往往比努力更重要。回顾过去十余年,这几个决定对我走到今天起到了至关重要的影响。

1. 毕业之后去上海

2009年刚毕业时,我的目标很简单,就是找到一份和专业相关的工作,不论在哪,不论具体做什么,没任何计划,只要能提供一份能养活自己的工作就行。

当时,有同学已经找到手机测试的工作,并被派到上海出差,我得知之后他们还在招聘,也应聘了这家公司。

还记得应聘完不久,我就坐上了回家的火车。列车从沈阳北站出发时,我接到了公司的电话,通知我面试通过,可以来签合同了。就在火车到达沈阳站时,我毫不犹豫地下了车,还退掉了火车票,开始了人生的第一次真正选择。

我的第一份测试工作就这样开始了。那时候真的很敢闯,说走就走,然后就独自一个人去了上海。

上海对我来说是一个新鲜的、充满魔力的城市,即使是住在公司郊区的宿舍,生活依然快乐和精彩。

在上海,我去过世博会、首家苹果店开业,当然还有南京路、外滩、杭州西湖;还看过刘翔在钻石联赛跑110米跨栏,看周杰伦的上海演唱会。周末的晚上还会和同事一起聚餐到半夜,那时候大家都是刚毕业的小伙子,同事之间相处起来更像是同学。

2. 从上海回到沈阳

在上海出差了一年多,又到了选择的时候,是回到沈阳分公司还是辞职在上海找一份新的工作?我和一部分同事选择回到沈阳分公司。

回到沈阳,那里的办公室、食堂、工厂和宿舍都在一个大大的厂区里,周围是郊区,只有周末才能出去逛逛。

我感觉到在这个郊区,我就是这个工厂里的螺丝钉,看到了那种一眼望到头的生活。

日子虽然过得平稳,但不应该是我这个二十来岁的年龄该追求的,我知道这不会持续太久,如果不及时调整,等到有一天没什么一技之长时会很被动。我开始思考:如果将来我想去大连,我现在的这份手机测试是很难找到工作的,因此我要转做 Web 测试,哪里要我,我就去哪里,我需要的就是相关工作经验。

后来我是在沈阳东软面试上了北京东软的岗位,去北京的工资是3000,于是我毅然决然去了北京。

3. 从沈阳到北京

那是2011年3月,来之前我联系了大学同学刚哥。我可以在找到房子之前在他那里借宿一段时间。

就这样,我就坐上了去北京的火车。

我如愿做上了我心中真正的软件测试工作,也从那时候开始,我才开始上手了一点脚本、数据库相关的知识。

在北京东软,我经历了两个外派项目,发现我不喜欢这样的外派方式。一是上班无定所,二是定期更换并认识新同事。不到一年时间,我打算换工作了。

我第一个投递的简历是百度,面试了但不知道为什么反正就是没有通过,可能那时候确实是太菜了,才做了不到一年的 web 测试新手,还想面试百度?想想也不太可能。

后来又投了几个简历,误打误撞我就面试了京东,且最终通过了面试。记得当时的工资是6500,这对我来说真的是一笔巨款啊,足足比我刚来北京的时候翻了一倍。

在京东工作的两三年,是我真正入行测试的几年。身边确实有一些值得学习的同事,在他们身上我学到了 Python、Jenkins、性能测试、以及功能测试。

虽然我学到了这些技能,但我知道如果我想回到大连找到一份不错的工作,光会点技术还不够,我还得会英语,因为在大连只有外企的待遇还不错。

因此我在北京就开始搜索大连的外企,另外也开始准备学习英语。

我报名了新东方,学费好几千块钱,我记得上一堂课可能都要几十到上百,另外我觉得这样性价比不高。听了一两次试听课后,我果断退了学费。

我觉得最好的学习英语的环境就是加入外企。我开始在北京尝试去面试大连的外企,正好有一家在北京有分公司,我就去面试了,但可惜面试没通过。

4. 从北京回到大连

没有办法,在北京想找到大连外企实在不太现实,我辞掉了京东的工作回到大连找。

回到大连之后休息了几天,发现自己没有工作实在没心情做其他任何事情,然后就开始了找工作。

去面试过花旗的外派,也没有成功。那时候我还有一个想法就是转开发!

这是受在京东的同事影响。当时有一个测试同事,他会开发且技术不错,负责给开发团队写单元测试。我当时觉得这个很厉害,我也想做那种被认为有技术含量的工种。

因此我当时的另一个计划是:如果有任何一家公司愿意招聘我这个只有测试工作经验的人,培养我做开发,我其实愿意少拿钱,甚至免费为他们工作。我当时离开京东时的工资已经有一万二了,尽管如此但我也想要转开发,即使是从一个实习生开始。可惜当时市场没有给我这个机会,我没有在短期内找到这样的开发岗位。因为我需要一份工作,后来就找到一个6000多薪资的测试小主管工作。在这个岗位上我工作了几个月,发现这不是我想继续工作的环境,并在骑驴找马继续寻找一份外企工作。

后来我又误打误撞投了我之前在北京投递过的外企,这次面试得挺不错的,并正式被录用进入了外企。在这里开启了一段十年的职业生涯,是我最为努力的十年。

5. 在外企从测试转开发然后DevOps

上面说过我想转开发。在我加入到新公司后,组内有机会可以从测试转前端开发的机会。我当时极度羡慕这样的机会,可惜晚了一步,人够了,因此我就只能在测试岗位上继续发光发热。

直到2018年,因为公司业务调整,我又有了转开发的机会,但需要考核。

虽然对我来说是一个很大的挑战,但我认为这对我来说是在做对的事情。两个原因:

  • 如果编程技能比较强,我可以成为测试里技术最好的人;
  • 通常开发比测试有更多的话语权,更多的机会,比如说技术移民。
    我毫不犹豫地申请去做开发!

那是一段压力非常大的日子,我之前在#码农随笔系列里写过文章记录过那段日子。但最后我还是成功做了开发。再后来团队需要一个Build工程师,说真的,真是为我准备的角色,太适合我了!

之前这个角色还叫Build工程师,因为我非常有热情把这个工作做好,因此我做了很多Build之外的事情,因此我的职责也在慢慢扩大到DevOps相关领域,之后大家都称我为DevOps工程师,负责DevOps/Build/Release相关的事情。

6. 从大连到欧洲

早在几年前,我开始有了想走出去看看的想法,想在日本、欧美范围内找一个可以提供签证的DevOps工作。如果再走不出去,到了四十岁我可能就没什么机会了。

这个想法的产生可能源自于我此前自由行去过泰国、日本、美国的缘故。之后我喜欢听《静说日本》、《随口说美国》这些音频节目。

我更新了自己的LinkedIn,期间偶尔有人联系过我新加坡的机会。说实话,能不能去成还不好说,但我对那里不是很感冒,给我的感觉那边比较卷。

在经历了疫情、孩子出生后,这个想法就搁置了,也没有任何进展。在经历了众所周知的大环境后,突然有了机会。

但说实话这时候我顾虑比当初去上海,回沈阳、去北京、回大连时多得多。

因为家庭、因为孩子、因为父母,做出决定是不容易的。但在过往的所有选择里,没有完美的机会,在这个不确定的时代,唯一不变的就是变化。况且这样的机会以后几乎都不会再有了。

留下来可能需要被迫去卷无意义的事情,就像大人卷工作、教育,小孩卷学习。想到此,我知道又到了该选择的时候,那就是走出去。

最后

自毕业以来,特别是近十年的外企工作,我挺努力的。努力工作、不妥协地去完成;坚持业余时间以教促学的写了七八年的博客和公众号,贡献开源项目。

我坚信努力的价值,但同时也提醒自己不要陷入“自我感动”的误区。努力固然重要,但不能让战术上的勤奋掩盖战略上的懒惰。我们必须抬头看路,抓住关键的机会,做出明智的决策。毕竟,如果方向错误,再多的努力也可能是徒劳的。


转载本站文章请注明作者和出处,请勿用于任何商业用途。欢迎关注公众号「DevOps攻城狮」

DevOps进阶:揭秘首席DevOps工程师的职责与技能

想象一下,你是一名 DevOps 工程师,不论初级、中级还是高级,老板总有一天拍拍你的肩膀说:“加油干,兄弟,未来你就是我们的首席 DevOps 工程师了!”你可能会心想:“啥是首席 DevOps?这是个什么新饼?”

今天就带你了解一下,所谓的“首席 DevOps 工程师”到底干啥,职责是什么?

我们一起看看,顺便找准未来的职业发展方向。毕竟,谁都希望能进阶到高级角色嘛,对吧?

首席 DevOps 工程师是干啥的?

在今天这个技术跑得比人快的世界里,首席 DevOps 工程师是关键角色,帮助企业搞定基础设施,让软件交付又快又稳。这可不光是架个服务器那么简单,真正的大活儿是当好开发和运营团队之间的“桥梁”,推动 DevOps 文化在公司生根发芽。

那么他们的日常是啥呢?总结起来,有三个主要工作:

  1. 设计并维护基础设施 —— 和开发团队配合,搭建弹性、可扩展的基础设施,满足业务需求。
  2. 自动化所有能自动化的事情 —— 减少手动操作,提升代码发布和测试的效率。
  3. 推动团队文化变革 —— 推广 CI/CD 最佳实践,优化大家的工作方式。

核心职责

1. 协调开发和运营

在你成为首席 DevOps 工程师后,你的头号任务就是让开发和运营两边配合得像一个人。持续集成、持续部署这些词你得说得像背诗一样顺溜,同时,基础设施得稳如老狗。

2. 实现自动化和流程优化

自动化是 DevOps 的灵魂,首席 DevOps 工程师就是得把那些繁琐的手动任务尽可能自动化,不断优化,让所有事情跑得又快又稳。

3. 保证系统可靠性和效率

系统跑不稳,CI/CD就得停摆,所以你要设计出能撑得住风浪的基数设施。遇到高负载或者故障,系统照样得稳住。定期监控、优化,是你的日常功课。

成为首席 DevOps 工程师需要哪些技能?

1. 技术要硬

技术基础是标配,Python、Bash 这些脚本语言得熟悉,Docker 这种容器技术也得懂,Ansible、Chef 这些配置管理工具是你日常操作。最重要的是,云平台(比如 AWS 和 Azure)管理经验不能少。

2. 领导力和管理能力

技术大牛不稀奇,领导力大牛才是硬通货。你得激励团队,帮他们成长,创造出协作的氛围。别忘了,技术再牛,不会跟不同层级的利益相关者沟通,那也白搭。

3. 解决问题的能力

技术上碰到过问题可以迅速找到问题的根源,给出靠谱的解决方案。更重要的是,做决策时得能平衡技术需求和业务目标,让公司上下都买账。

对公司有啥好处?

1. 加强沟通协作

作为首席 DevOps,你不仅仅写代码,还得跨团队沟通协调,让大家更默契,工作更顺畅。减少内部摩擦,提升效率。

2. 加快产品交付

优化流程、自动化任务,你能让产品的交付速度快得像坐火箭。市场变化快,你得让公司跟得上,产品能快速迭代,企业才能有竞争力。

3. 提高系统稳定性和安全性

稳定性和安全性很重要,你得建立起强大的监控体系,防止潜在的威胁,在安全和稳定方面给公司打下坚实基础。

总结一下

首席 DevOps 工程师可不是单纯的技术专家,你要靠技术提升效率,推动合作,保证产品交付和系统的稳定性。这过程里,你不仅是一个技术领袖,更是团队文化的推动者。

想成为首席 DevOps?那就不仅要技术过硬,还要培养领导力和解决问题的能力。

希望这篇轻松的文章能帮你找到未来的努力方向,毕竟,我们都在为更高的目标努力着!


转载本站文章请注明作者和出处,请勿用于任何商业用途。欢迎关注公众号「DevOps攻城狮」

约定式分支规范中文版正式发布!

上周正式发布《约定式分支规范》后,受到了广泛关注,不少人询问何时推出中文版。

经过一周末的努力,中文版已正式上线,详情请访问:**https://conventional-branch.github.io/zh/**。

此外,我们对原始版本进行了部分细微调整。以下为《约定式分支规范》中文版的完整内容。

概述

约定式分支是指 Git 分支的结构化和标准化命名约定,旨在使分支更具可读性和可操作性。我们建议了一些您可能想要使用的分支前缀,但您也可以指定自己的命名约定。一致的命名约定使按类型识别分支变得更加容易。

要点

  1. 以目的为导向的分支名称:每个分支名称都清楚地表明了其目的,使所有开发人员都能轻松了解该分支的用途。
  2. 与 CI/CD 集成:通过使用一致的分支名称,它可以帮助自动化系统(如持续集成/持续部署管道)根据分支类型触发特定操作(例如,从发布分支自动部署)。
  3. 团队协作:它通过明确分支目的来鼓励团队内部的协作,减少误解并使团队成员更容易在任务之间切换而不会产生混淆。

规范

分支命名前缀

分支规范通过 feature/bugfix/hotfix/release/chore/ 来描述,其结构应如下:


<type>/<description>
  • main:主要开发分支(例如 mainmasterdevelop
  • **feature/**:用于新功能(例如 feature/add-login-page
  • **bugfix/**:用于错误修复(例如 bugfix/fix-header-bug
  • **hotfix/**:用于紧急修复(例如 hotfix/security-patch
  • **release/**:用于准备发布的分支(例如 release/v1.2.0
  • **chore/**:用于非代码任务,如依赖项、文档更新(例如 chore/update-dependencies

基本规则

  1. 小写字母和连字符分隔:始终使用小写字母,并使用连字符分隔单词。例如,feature/new-loginbugfix/header-styling
  2. 仅使用字母数字和连字符:仅使用小写字母 (a-z)、数字 (0-9) 和连字符。避免使用空格、标点符号和下划线等特殊字符。
  3. 无连续连字符:确保连字符单独使用,没有连续的连字符(例如,feature/new-login,而不是 feature/new--login)。
  4. 无尾随连字符:请勿在分支名称末尾添加连字符。例如,使用 feature/new-login 而不是 feature/new-login-
  5. 清晰简洁:使分支名称具有描述性但简洁。名称应清楚地表明正在完成的工作。
  6. 包括 Jira(或其他工具)票号:如果适用,请包括项目管理工具中的票号,以便于跟踪。例如,对于票号 T-123,分支名称可以是 feature/T-123-new-login

结论

  • 清晰的沟通:仅凭分支名称就能清楚地了解代码更改的目的。
  • 自动化友好:轻松挂接自动化流程(例如,针对 feature, release 等的不同工作流程)。
  • 可扩展性:适用于许多开发人员同时处理不同任务的大型团队。

总之,约定式分支旨在改善 Git 工作流程中的项目组织、沟通和自动化。

常见问题

如果团队成员不符合此规范,可以使用哪些工具来自动识别?

你可以使用 commit-check 来检查分支规范,或者如果你的代码托管在 GitHub 上,则使用 commit-check-action


感谢大家的关注!最后,欢迎Star、转发或建议。


转载本站文章请注明作者和出处,请勿用于任何商业用途。欢迎关注公众号「DevOps攻城狮」

Conventional Branch Specification Released!

Summary

Conventional Branch refers to a structured and standardized naming convention for Git branches which aims to make branch more readable and actionable. We’ve suggested some branch prefixes you might want to use but you can also specify your own naming convention. A consistent naming convention makes it easier to identify branches by type.

Key Points

  1. Purpose-driven Branch Names: Each branch name clearly indicates its purpose, making it easy for all developers to understand what the branch is for.
  2. Integration with CI/CD: By using consistent branch names, it can help automated systems (like Continuous Integration/Continuous Deployment pipelines) to trigger specific actions based on the branch type (e.g., auto-deployment from release branches).
  3. Team Collaboration : It encourages collaboration within teams by making branch purpose explicit, reducing misunderstandings and making it easier for team members to switch between tasks without confusion.

Specification

Branch Naming Prefixes

The branch specification by describing with feature/, bugfix/, hotfix/, release/ and chore/ and it should be structured as follows:


<type>/<description>
  • main: The main development branch (e.g., main, master, or develop)
  • feature/: For new features (e.g., feature/add-login-page)
  • bugfix/: For bug fixes (e.g., bugfix/fix-header-bug)
  • hotfix/: For urgent fixes (e.g., hotfix/security-patch)
  • release/: For branches preparing a release (e.g., release/v1.2.0)
  • chore/: For non-code tasks like dependency, docs updates (e.g., chore/update-dependencies)

Basic Rules

  1. Lowercase and Hyphen-Separated: Always use lowercase letters, and separate words with hyphens. For example, feature/new-login or bugfix/header-styling.
  2. Alphanumeric and Hyphens Only: Use only lowercase letters (a-z), numbers (0-9), and hyphens. Avoid special characters like spaces, punctuation, and underscores.
  3. No Consecutive Hyphens: Ensure that hyphens are used singly, with no consecutive hyphens (e.g., feature/new-login, not feature/new--login).
  4. No Trailing Hyphens: Do not add a hyphen at the end of the branch name. For instance, use feature/new-login instead of feature/new-login-.
  5. Clear and Concise: Make branch names descriptive but concise. The name should clearly indicate the work being done.
  6. Include Jira (or Other Tool) Ticket Numbers: If applicable, include the ticket number from your project management tool to make tracking easier. For example, for a ticket T-123, the branch name could be feature/T-123-new-login.

Conclusion

  • Clear Communication: The branch name alone provides a clear understanding of its purpose the code change.
  • Automation-Friendly: Easily hooks into automation processes (e.g., different workflows for feature, release, etc.).
  • Scalability: Works well in large teams where many developers are working on different tasks simultaneously.

In summary, conventional branch is designed to improve project organization, communication, and automation within Git workflows.

FAQ

What tools can be used to automatically identify if a team member does not meet this specification?

You can used commit-check to check branch specification or commit-check-action if your codes are hosted on GitHub.


转载本站文章请注明作者和出处,请勿用于任何商业用途。欢迎关注公众号「DevOps攻城狮」

初步了解 PyPA(Python Packaging Authority)下的知名项目和关系

PyPA(Python Packaging Authority)是管理和维护 Python 包相关工具的一个社区组织。PyPA 管理的知名项目包括 pip、packaging、setuptools、wheel、twine、build 等等。了解这些项目的关于有助于我们更好的了解 Python 的生态系统。

以下是这些项目的介绍以及它们之间的关系:

  1. pip

作用:pip 是 Python 的包管理工具,用于安装和管理 Python 库和依赖项。通过 pip,用户可以从 Python Package Index (PyPI) 或其他包源下载并安装所需的 Python 包。
关系:pip 依赖于 setuptools 和 wheel 来处理包的构建和安装。它是最常用的 Python 包管理工具,也是官方推荐的包安装方法。

  1. setuptools

作用:setuptools 是一个用于打包 Python 项目的工具,可以创建分发包(distribution packages)并发布到 PyPI。它扩展了 Python 标准库中的 distutils,提供了更多功能,如依赖管理、插件系统等。
关系:setuptools 是创建 Python 包时常用的工具,pip 使用 setuptools 来安装源代码形式的 Python 包。setuptools 生成的分发包通常是 .tar.gz 或 .zip 文件格式。

  1. packaging

作用:packaging 提供了用于与 Python 包打包和分发相关的核心实用工具和标准实现。它实现了一些与包版本、依赖关系解析等有关的 PEP(Python Enhancement Proposals)。
关系:packaging 是 setuptools 和 pip 等工具的底层依赖,用于处理包的版本比较、依赖解析等低层次操作。

  1. wheel

作用:wheel 是一种 Python 包的打包格式,作为 setuptools 打包格式 .egg 的替代方案。它是目前推荐的发布格式,可以避免编译步骤,安装速度更快。
关系:pip 优先安装 wheel 格式的包,因为它可以直接安装,而不需要像 .tar.gz 那样进行编译。setuptools 可以生成 wheel 格式的包。

  1. virtualenv

作用:virtualenv 用于创建独立的 Python 环境,可以避免不同项目之间的包依赖冲突。每个虚拟环境都有自己独立的 Python 可执行文件和库集合。
关系:pip 被用于管理 virtualenv 中的包。virtualenv 是创建隔离环境的工具,但近年来 Python 标准库中的 venv 模块也能提供类似功能。

  1. twine

作用:twine 是用于将 Python 包上传到 PyPI 的工具。与 setuptools 的 python setup.py upload 方法不同,twine 更加安全,支持上传 wheel 文件和 .tar.gz 文件。
关系:twine 通常与 setuptools 或 wheel 一起使用,负责将构建好的包上传到 PyPI。

  1. build

作用:build 是一个简单的命令行工具,用于构建 Python 项目。它可以使用 PEP 517 接口构建包,而不依赖于 setuptools。
关系:build 提供了比 setuptools 更简洁的构建方式,但它依赖于 setuptools 或其他构建后端(如 flit、poetry)来实际完成构建过程。

  1. pyproject.toml

作用:pyproject.toml 不是一个工具,而是一种配置文件格式。它被用来描述项目的构建需求,并支持使用不同的构建后端,如 setuptools、flit、poetry 等。
关系:pip 和 build 等工具会读取 pyproject.toml 文件,了解如何构建和安装项目。

他们之间的关系总结

  • pip 作为包管理工具,与所有这些项目都有交互关系,尤其依赖 setuptools 和 wheel 来安装包。
  • setuptools 负责包的创建和打包,并使用 packaging 处理版本和依赖。
  • wheel 是打包格式,pip 更倾向于安装 wheel 格式的包。
  • virtualenv 用来创建隔离的环境,pip 被用来在这些环境中安装依赖。
  • twine 用来安全地上传包到 PyPI,通常与 setuptools 和 wheel 结合使用。
  • build 是一个新兴的构建工具,使用 PEP 517 接口,可以使用 setuptools 作为构建后端。

这些工具共同构成了 Python 包管理和分发的完整生态系统,简化了 Python 开发者的工作流程。


转载本站文章请注明作者和出处,请勿用于任何商业用途。欢迎关注公众号「DevOps攻城狮」

我记得

最近开车的时候我总爱听赵雷的歌,尤其是那首《我记得》。

我觉得这首歌就是回忆的交响曲,每每听到就仿佛看到了一部老电影。它像是一种声音,一种触动人心的触感,让我们回忆起那些已经消逝的时光,反思我们的生活方式和人生的方向。

歌词和旋律中都充满了满满的怀旧情感,总是让我回想起来这一段时间来的所有人多我的问候和祝福。

趁着他们都还很鲜活我想把他们全都记录一下,也叫《我记得》:

  • 6月14日(周五)我所在的1024足球队就为我准备了聚餐,当时还只有我的签证获批,这已经是一个好的开始了,当晚把我这几年的啤酒全喝了,还好酒精度数不是很大,回到家也没有迷糊。
  • 6月27日(周四)与公司的同事和领导去吃了钱库里自助,当时的心情还是复杂的,因为明天就要毕业了,我们在一起照了一张欢快的合影。
  • 6月28日(周五)毕业当天很多同事过来跟我告别、以及他们把我送出公司的门和大楼门的情景,最后我和大超一起下山,他回家,我等公交车。
  • 6月30日(周日)我去小平岛恰巧碰到了同事大叔,我去送洗鞋,他去买菜。我们就站在马路边站着聊了很久,最后分别前拍了一张合影。
  • 7月1日(周一)跟当年的发小和老同桌一起吃了午饭,绕着腾飞走了一圈,最后他陪我一起去4s保养、补胎,聊了一下午,好久没有单独和一个人聊这么久了,感觉很好,拍了合影,留作纪念
  • 7月4日(周四)我独自带着女儿回到老家让二老再看看他们的大孙女,整个往返车程6个小时,女儿都是坐在宝宝安全座椅上,表现的非常棒。
  • 7月7日(周日)和妻子、女儿去老丈人家吃了一个美味的午饭;还是当天,下午和教练去市馆游泳,回到腾飞后喝了杯咖啡、吃了点小食、最后绕着腾飞走了半圈,聊到意犹未尽。
  • 7月8日(周一)去跟原公司同事蹭场打羽毛球,
  • 7月9日(周二)跟1024足球队踢了我在这边的最后一场球了,对方今天有一个超强的守门员,给人印象深刻,另外一个深刻的地方可能就是我的一记后场吊射进球了吧。
  • 7月10日(周三)启程再次去日本拿卡,另外还去了一趟东京迪斯尼,尽管当天下了雨,但感受还是很好。
  • 7月14日(周日)从日本回来,当天下午前同事朋友去羊汤馆吃了一顿饭,聊了几个小时。
  • 7月15日(周一)见了发小,他在海边钓鱼,我也去了,那是我第一次使用鱼竿钓鱼,并且钓到了一条小小小鱼。
  • 7月16日(周二)启程出发了,虽然心中有万般不舍,但到了改走的时候了。我知道此时的难过是真的,我也知道我一定会走出这一步也是真的。当晚做高铁到了北京,见到机场见到大学同学,一起聊了一会,但因为已经很晚了,就叙旧到此。
  • 7月17日(周三)经过了十几个小时的飞行,我们一家人终于到了维村。至此,我短暂的毕业季就结束了。

很怀念,因此写下只言片语,记录一切发生过的美好。

这些记忆会提醒我,无论生活如何变迁,我们都不会忘记过去,但也要对未来充满希望和期待,体验到了生活的美好和希望。

生活里虽然充满了困难和挑战,但只要我们对过去有回忆,对未来有期待,那么生活就充满了意义和价值。

美好的音乐也会触动着我们的情感,引发我们的思考,带给我们力量和希望。


转载本站文章请注明作者和出处,请勿用于任何商业用途。欢迎关注公众号「DevOps攻城狮」