在焦虑的长夜中,这首诗总能让人切身的体会到当年苏轼老师的感受,时过境迁,来到我们所谓的现代化社会,又有多少人会有同样的情感?漫漫历史长河在浩瀚的宇宙里,也非常短暂,所以这首跨越了将近千年的诗,在现在看起来也是非常贴切,能够引起很多人的共鸣。
大家五一快乐,好久不见,失踪人口回归啦!这段时间接触游戏研发管理比较多,对游戏的行业发展、技术架构、研发模式等方面有了一些新的认识,毕竟自己曾经也是「游戏厅三王子」,曾经荣获「拳皇97战神」、「西游&三国一币通关王」等称号(手动狗头),当年玩游戏的时候就对游戏的制作有很多疑惑,最近总算是有了一定的了解了,所以写写分享给大家。
前段时间 Git 发布正式版本 2.33.0 遇到一个客户端与服务端不兼容的一个问题,在排查问题的过程中又一次用到了 Git bisect 命令,解决问题的同时结合近期的一些认知,又刷新了自己对 bisect 命令的认识,bisect 可以结合一些场景发挥其妙用,借此分享下 bisect 命令以及 bisect 命令的一些其它使用方式的思考。
企业从内部开源到外部开源,是没有办法完全复制企业内源那套玩法的,虽然二者有很多共性,但毕竟参与者从企业内部员工直接扩大到了整个社会,在协作方面还是有不少差异的。这篇文章主要是基于对 Huawei 在 Gitee 上开源项目的协作方式,一步一步分析开源软件的协作模式,以及一些企业参与开源需要注意的事项。
无论是工作还是生活,方方面面无不体现同理心作用,绝大多数情况下的事情,拥有同理心都会好办很多。无论是什么场景,同理心总有它奇妙的作用之处,每一个人都应该尝试多去换位思考,这个世界才会变的更加美好 ;D
去年写过一篇文章《浅谈 Pull Request 与 Change Request 研发协作模式》,详细介绍了 PR Flow 以及 CR Flow 的区别,文末有说到 Gitee 应该提供推送分支自动创建评审的这项改进,刚好近期也听到很多关于平台支持 CR Flow 的声音,而且在不少客户内部也有类似需求,毕竟这个需求可以解放开发者的一部分精力,对于追求研发效能的当下,自然是一个不错的功能点,另外对于 Gerrit 转到 Gitee 的用户,也是一个平滑的过渡方案。所以写下这篇文章,探讨一下支持 CR Flow 平台的产品实现,并对 CR Flow 实现的底层原理做了一些实验性的工作,以供参阅。
码云 Gitee 自2013年推出以来,每年的数据量都是倍增的,截止到2021年3月份,Gitee 上已经有了600万+的开发者,超1500万的仓库,成为了国内首屈一指的研发协作平台。在数据日益增长的过程中,Gitee 的架构也是经过了数个迭代,才能支撑起目前的数据量级。我曾在不少的大会上分享过 Gitee 的架构,也和很多有类似场景的同学一起讨论过,偶然被问起有没有专门的文章来介绍 Gitee 架构的,所以难得假期有时间,将此主题整理成文,以供大家参阅。
无意翻出这篇写于两年前的手稿,当时交付的几家私有云大客户以及公有云客户均频繁遇到此问题,虽然现象千奇百怪,但是无非是错误的操作导致的代码丢失,秉承着开放、自由、分享的开源精神,把相关的错误操作整理出来并加以说明,对于新老用户都是一种引导,不仅可以避免给团队带来麻烦,也使自己能够更好的理解 Git 的一些运作方式,所以整理成文,希望能够帮助到有需要的人,尤其是公司内部研发流程的培训上,更应该关注这一类误操作的普及和说明,避免「不了解」给团队带来的麻烦。
Git 是目前最流行的版本控制系统,从本地开发到生产部署,我们每天都在使用 Git 进行我们的版本控制,除了日常使用的命令之外,如果想要对 Git 有更深一步的了解,那么研究下 Git 的底层存储原理将会对理解 Git 及其使用非常有帮助,就算你不是一个 Git 开发者,也推荐你了解下 Git 的底层原理,你会对 Git 的强大有一个全新的认识,并且将会在日常的 Git 使用过程中更加得心应手。
众所周知,Git 是当前最流行的分布式版本控制系统,近两年由于 DevOps 的迅速发展,一切皆代码正在成为标准实践。而这一切,都需要有一个配置管理中心统一管控,Git 毫无疑问的成为了这个领域的宠儿。日常开发工作中,我们经常用不同方式去下载和上传代码到 Gitee,那么这背后是如何实现的呢,让我们一起来聊聊 Git 不同的传输协议以及具体的实现。
在开源理念日渐活跃的今天,越来越多的人开始投身于开源,贡献了越来越多的开源项目。而随着时间的推移,更多的人开始为开源项目添砖加瓦,为某一领域的开源项目贡献出自己的力量。贡献者的增多又给开源作者带来不少审核的压力,实际上投身开源的这些开源作者基本都是业余时间来做,并没有太多的时间投入在开源项目上。本文就为了解决这类场景,介绍下如何在 Gitee 上通过 Jenkins 来为自己的开源项目开启自动化协作,旨在将一些开源相关的工作自动化,留出更多的时间投身开源事业。
说起 PullRequest 相信大部分人都不会陌生,它是由 Github 推出的一种开源协作模式,由于 Gitlab 占据着企业内部私有部署的半壁江山,这种模式也更多的用在企业内部代码审核流程,也就是所谓的 CodeReview。其实还有很多企业和团队会选择 Gerrit 这个工具,Gerrit 提供的是 ChangeRequest 模式,这种模式更具有针对性,对代码审核的粒度也更细,近期有客户需求在 Gitee 上实现类似 ChangeRequest 的需求,所以针对两种模式做一个介绍,探讨两种模式的具体适用场景。
最近看到了一篇文章,细讲了各种分布式调度原理,其中加权轮询算法(Weighted Round-Robin)应该是离我们最近的一种方式了,Nginx 的 Upstream 就是用的这个算法,这个算法可以根据权重使得每个服务器能够均匀的负载请求,本篇主要就是来总结下使用这个算法以及 Go 内置的方法来实现一个简单的加权轮询的 HTTP 负载分发代理,并对负载分发及路由做一些延伸思考。
前面我们介绍了 Jenkins 相关的流水线以及可视化编辑流水线的 BlueOcean 插件,接下来我们主要通过一些实际的应用,来介绍下 Jenkins 在实际工作中的应用,同时也能够避免枯燥乏味的功能介绍,直接切入应用,这样来的比较有成就感。近期也是因为公司工作调整,突然间多了很多事,所以停更了一个月,晚上睡觉想起倍感羞愧,不敢睡觉,于是赶紧补上此篇博客来弥补内心的空缺 ;D
上篇中我们介绍了 Pipeline 的语法,也可以通过 Pipeline Editor 进行编辑,但是这些还不够,Jenkins 团队为了用户更方便的使用流水线,降低用户使用成本以及优化用户使用体验,推出了 BlueOcean,BlueOcean 是以插件的形式存在的,用官方的话说就是重新思考用户体验,它提供了一个更加灵活的流水线编辑器,允许你更加直观的进行流水线的定制,更加直观的观察到每一个步骤甚至每一个任务的运行状况。