在程序员圈子里比较流行这样一句话“会写程序的干不过会写 PPT 的”,还记得 2019 年新东方年会的一首《放飞自我》里有这样一句歌词戳中了绝大大多数程序员的内心
“干的累死累活,有成果那又如何,到头来干不过写PPT的”。
一时间大家好像都认同了这个说法,表达着自己的不满和无奈。
在程序员圈子里比较流行这样一句话“会写程序的干不过会写 PPT 的”,还记得 2019 年新东方年会的一首《放飞自我》里有这样一句歌词戳中了绝大大多数程序员的内心
“干的累死累活,有成果那又如何,到头来干不过写PPT的”。
一时间大家好像都认同了这个说法,表达着自己的不满和无奈。
我在做 Jenkins 声明式流水线开发时常会遇到的问题是:修改后的 Pipeline 看起来没有问题,当提交到代码仓库后进行 Jenkins 构建时发现原来有语法错误,然后再去修改、提交、构建,结果可能还有有其他没有注意到的语法问题。
为了减少这种因为语法错误而需要频繁像代码库去提交的情况,如果能在提交之前进行基本的语法校验,来检查当前的 Pipeline 是否存在语法错误就好了。
经过调查发现 Jenkins 本身提供了这样的语法检查 REST API,可以直接使用这个 API 来对 Pipeline 声明式进行语法校验,这个方式需要执行一长串的 curl
命令,看起来似乎很麻烦,如果能在 IDE 里直接运行就好了。
VS Code 作为当前当前最流行 IDE 工具,果然找到了相关的插件。
以下就介绍两种方法:针对 Jenkins 声明式流水线中的 Jenkinsfile 文件进行语法错误检查,这两种方式的原理都是通过调用 Jenkins REST API 来实现的。
Nightwatch js 是我之前写自动化测试用例使用了很长一段时间的测试框架,我当时的使用 v0.9 版本并且对使用和 API 进行了翻译。作为一名前测试工程师,对于自动化的知识不能不更新下自己的知识库,一转眼 Nightwatch 1.3 版本已经发布了,可以看到它在 GitHub 上的使用和关注度还是很高的。
Nightwarch.js 是一个端到端的基于 Node.js 使用 W3C Webdriver (以前是 Selenium )的自动化测试框架。它是一个完整的集成解决方案,用于 web 应用程序和网站的端到端测试,以及 Node.js 单元测试和集成测试。
use JMeter’s HTTP(S) Test Script Recorder, please refer to this official document https://jmeter.apache.org/usermanual/jmeter_proxy_step_by_step.html
Debug scripts on JMeter in GUI Mode
You can debug your record scripts in GUI Mode until there are no errors
run test scripts in Non-GUI Mode(Command Line mode) recommend
jmeter -n -t ..\extras\Test.jmx -l Test.jtl |
Jenkins 的 multi-branch pipeline 想必很多人已经在用了,使用这种类型的 Jenkins Job 最显著的作用就是可以对 Git 仓库里的任何分支和任何 Pull Request(以下简写为 PR)进行构建。
在做 Jenkins 与 Bitbucket 的集成时,需要安装插件:Bitbucket Branch Source,可以通过该插件在 Jenkins 里进行 webhook 的配置。这种方式对于没有 Bitbucket 仓库的管理权限,CI/CD 暂且处于变更比较频繁的阶段,不想麻烦的去申请添加 webhook 的同学来说是非常友好的,就是可以不用通过管理员在 Bitbucket 设置里添加 webhook 也可以实现创建 PR 后触发 Jenkins 构建。
但我最近遭遇了两次:在创建 PR 后没有触发 Jenkins 自动构建,查了 Jenkins 和 Bitbucket Branch Source 插件的配置,并没有任何改动,也各种 Google 之后也没有找到相应的解决办法(如果有遇到此情况的小伙伴欢迎一起交流)。
那既然这条路不稳定,不好走,那就走一条可以走通的路、直接的硬路,即在 Bitbucket 对应的仓库中添加 webhooks。
I have set several multi-branch pipeline and it can support Bitbucket Pull Request build. So, when developer create a Pull Request on Bitbucket, Jenkins can auto-trigger PR build. but this jenkins-plugin may not very stable, it had not work two times and I actually don’t know why it does that. But I know the use Git webhook is a direct and hard approach could solve this problem. After my test, the answer is yes. it works as expect.
这是我第二次在使用 Jenkins 声明式流水线的时候遇到了这个问题,第一次遇到这个问题的时候是在一个 Pipeline 里大概写到 600 多行时候遇到如下错误
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: |
什么是DevOps
用最简单的术语来说,DevOps是产品开发过程中开发(Dev)和运营(Ops)团队之间的灰色区域。 DevOps是一种在产品开发周期中强调沟通,集成和协作的文化。因此,它消除了软件开发团队和运营团队之间的孤岛,使他们能够快速,连续地集成和部署产品。
什么是持续集成
持续集成(Continuous integration,缩写为 CI)是一种软件开发实践,团队开发成员经常集成他们的工作。利用自动测试来验证并断言其代码不会与现有代码库产生冲突。理想情况下,代码更改应该每天在CI工具的帮助下,在每次提交时进行自动化构建(包括编译,发布,自动化测试),从而尽早地发现集成错误,以确保合并的代码没有破坏主分支。
什么是持续交付
“Quality at Speed” 是软件开发中的新规范。
企业正在朝着 DevOps 方法论和敏捷文化迈进,以加快交付速度并确保产品质量。在 DevOps 中,连续和自动化的交付周期使快速可靠的交付成为可能的基础。
这导致我们需要适当的持续集成和持续交付(CI/CD)工具。 一个好的 CI/CD 工具可以利用团队当前的工作流程,以最佳利用自动化功能并创建可靠的 CI/CD 管道为团队发展提供所需的动力。
随着市场上大量 CI/CD 工具的出现,团队可能难以做出艰难的决定来挑选合适的工具。该列表包含市场上最好的 14 种 CI/CD 工具及其主要特性,使你和团队在选择过程中更加轻松。