公众号:DevOps在路上|专注于团队研发效能
这篇文章是一位DevOps实践者对云效流水线Flow的评测。首先介绍了自己参与评测的背景,并对Flow的易用性给予了肯定,认为它适合新手,尤其是可视化的编排功能。然后,作者讨论了Flow在新人上手、产品功能、性能和开放性方面的表现,指出Flow在插件开发能力和YAML编排体验上存在提升空间。他还提到了YAML编排的学习曲线和与可视化的结合问题,以及任务管理和步骤名称的混淆。此外,作者建议Flow增强模块间的逻辑性和交互清晰度,以提供更顺畅的工作流程体验。最后,作者总结了Flow的优点(功能齐全,适合中小企业)和需要改进的地方(业务逻辑、制品库能力和私有化场景的支持),并对其未来发展提出了期待。
一名DevOps实践者参与了云效流水线Flow的评测,认为Flow对新手友好,具有可视化编排功能。但在上手过程中,了解相关术语和流畅编排设计可能构成一些挑战。Flow的功能基本满足需求,但开放性有待提高,建议开放插件开发以丰富生态。YAML编排作为趋势,Flow在易用性和功能完善上仍有进步空间,如语法检查、智能提示等功能。此外,产品模块间的逻辑性和交互清晰度也需改进。总结来说,Flow功能齐全,适合中小企业,但在用户体验和生态建设上有改进余地。
Jenkins 很酷,但是不完美,有历史局限性造成的问题。本文仅从“如何更好给研发团队赋能的角度”,剖析Jenkins, 探讨理想的持续交付平台, 不带货无广告~
部署和发布是软件工程中经常互换使用的两个术语,甚至感觉是等价的。然而,它们是不同的! • 部署是将软件从一个受控环境转移到另一个受控环境,它的目的是将软件从开发状态转化为生产状态,使得软件可以为用户提供服务。 • 发布是将软件推向用户的过程,应用程序需要多次更新、安全补丁和代码更改,跨平台和环境部署需要对版本进行适当的管理,有一定的计划性和管控因素。
最近平台工程这个概念越来越火爆,Gartner 的预测,到 2026 年,80% 的软件工程组织将拥有平台工程团队,来提供内部服务、组件和应用程序交付工具,作为可重复使用的资源。本篇文章将带你走进平台工程,了解它的起源和解决的问题。
在实践中,很多团队对于DevOps 流水线没有很透彻的理解,要不就创建一大堆流水线,要不就一个流水线通吃。实际上,流水线的设计和写代码一样,需要基于“业务场景”进行一定的设计编排,特别是很多通过“开源工具”搭建的流水线,更需要如此(商业的一体化平台大部分已经把设计思想融入自己产品里了)。 • 流水线的设计与分支策略有关 • 流水线的设计与研发活动有关 清晰的代码结构,标准的环境配置,原子化的流水线任务编排,再加上团队的协作纪律,和持续优化的动作,才是真正的践行CI/CD实践
对象存储服务(Object Storage Service,OSS)是一种海量、安全、低成本、高可靠的云存储服务,适合存放任意类型的文件。容量和处理能力弹性扩展,多种存储类型供选择,全面优化存储成本。
随着越来越多的应用安全测试工具的出现,信息技术(IT)领导、开发人员和工程师可能会感到困惑——不知道哪些工具可以解决哪些问题。
选择合适的分支模型 Git代码分支管理模型各具特点,流程只是一个辅助工具,没有最好,只有最合适。 • 如果开发团队规模较小又比较分散,产品发布周期较短(例如:初创公司,或者开发的是一个网站或 Web 应用程序,在一天内可能需要发布多个版本),可以选择GitHub flow或者GitLab flow; • 如果开发团队规模较大,产品发布周期较长(例如:团队超过20人,采用了月度或季度发布周期,并且由一个团队负责并行开发多个项目),可以选择Git flow,发布周期较短可以选择TBD flow; • 如果开发团队规模大,产品发布周期长,同时对敏捷的要求比较高,可以考虑TBD++ flow。每个组织
DevSecOps — 在不影响敏捷性的前提下,将安全充分融入到SDLC的所有环节中 SDLC—软件交付生命周期 SCA—软件组成分析-用于识别和检测软件中使用的开源/第三方组件的已知安全漏洞 SAST—静态分析安全测试 DAS—动态分析安全测试 IAST—交互式分析安全测试 SBOM— 在这里特指软件中使用开源组件的完整信息列表
最近在学习实践精益Kanban方法,结合自己团队实践Srum的经历,整理些资料二者的差异。相较于Scrum, 我更推崇精益Kaban。
最近,无意中看到阿里云效推出了新的功能,需要进行评测,整好这个方案和我实际遇到的情况比较贴近,所以花点时间写下评测,表达下自己的看法。
当你打开这篇文章的时候,也许你也在为DevOps的落地而苦恼,也许你的组织正在尝试DevOps转型,作为一线的实践者,说说我对这个“落地难”的看法,欢迎交流不同看法~
DevOps方法论的主要来源是Agile, Lean 和TOC, 独创的方法论是持续交付。 DevOps 是一种软件开发方法,涉及持续开发,持续测试,持续集成,部署和监视。这一系列过程跨越了传统上孤立的开发和运营团队,DevOps 试图消除它们之间的障碍。 因此,DevOps 工程师基本上与 Development 和 Operations 团队合作,DevOps 是这两个主要部分之间的链接。
SonarQube是DevOps实践中主流的一款质量内建工具,过插件机制,Sonar 可以集成不同的测试工具,代码分析工具,以及持续集成工具,比如pmd-cpd、checkstyle、findbugs、Jenkins。 通过不同的插件对这些结果进行再加工处理,通过量化的方式度量代码质量的变化,从而可以方便地对不同规模和种类的工程进行代码质量管理。同时 Sonar 还对大量的持续集成工具提供了接口支持,可以很方便地在持续集成中使用 Sonar
现代软件开发过程中要实现高效的团队协作,需要使用代码分支管理工具实现代码的共享、追溯、回滚及维护等功能。目前流行的代码管理工具,包括CVS,SVN,Git,Mercurial等。 相比CVS和SVN的集中管理,Git具有非常明显的优势,例如:去中心化的代码管理方式减少了开发者对中心服务器的依赖,每个成员在本地都有一个完整的代码库,在不联网的情况下也能提交代码;不同于SVN中的每个分支具有独立的代码,Git中的每一个分支只是指向当前版本的一个指针,Git的分支策略使创建和合并分支变得快捷灵活。 从百度指数,也可以看到Git的优势被越来越多的人所认可。
谈到到DevOps,持续交付流水线是绕不开的一个话题,相对于其他实践,通过流水线来实现快速高质量的交付价值是相对能快速见效的,特别对于开发测试人员,能够获得实实在在的收益。很多文章介绍流水线,不管是jenkins,gitlab-ci, 流水线,还是drone, github action 流水线, 文章都很多,但是不管什么工具,流水线设计的思路是一致的。于此同时,在实践过程中,发现大家对流水像有些误区,不是一大堆流水线,就是一个流水线调一个超级复杂的脚本,各种硬编码和环境依赖,所以希望通过这篇文章能够给大家分享自己对于Pipeline流水线的设计心得体会。
制品管理是DevOps实践过程中的重要环节,起着承上启下,收集过程信息的重要角色; 于此同时,制品的引入使用会存在安全风险,组织需要关注这一点,避免类似Log4j2安全事件带来的一系列风险; 作为实践者,在制品的管理上需要结合组织和流水线需要,指定相应的规范,避免混乱; 好的制品管理流程,可减少开发自测和测试人员进行接收测试衔接过程中的低效沟通;