Details
Failure: PIP - Pip Inspector |
For more output please click to expand.
👉 Click to see more output 👈
[main] --- ======== Detect Issues ======== |
ENVIRONMENT:
- Product: synopsys-detect-7.11.1.jar
- Others: OpenJDK 11, Python 3.6 and Python 2.7.5
Failure: PIP - Pip Inspector |
For more output please click to expand.
[main] --- ======== Detect Issues ======== |
ENVIRONMENT:
DevOps 是 IT 界最近几年的一个热门话题,而且还会越来越热。
最近有幸和一位做传播咨询的读者朋友交流关于 2022 年最值得关注的 DevOps 趋势以及一些问题和回答,分享给大家。
无服务器计算是一种新兴趋势,实际上已经存在了十多年。企业购买无服务器框架需要一段时间,主要是因为对行业支持和对投资回报的担忧。
无服务器具有许多越来越难以忽视的优势,主要的两个最大好处是效率和可靠性。没有基础设施管理的负担,企业可以将资源集中在正重要的事项上。此外,无服务器还降低了传统框架可能出现的潜在维护问题的风险。
无服务器提供固有的可扩展性和可靠性并自动化开发人员不喜欢的日常操作任务,2022 年无服务器计算会经历下一次发展。
随着无服务器计算在 2022 年的发展,微服务也将如此。
微服务架构是将单体应用分化为小的独立单元,或服务,从而为大型团队提供了更大的灵活性。它有以下优势:
当然也必须认识到微服务的一个弊端,如果实施不佳可能导致严重问题,包括数据丢失、可靠性差和安全风险。
在写博客和公众号这件事上,不知不觉已经是我的第五个年头了,没想过能这么久。
借此分享一下这些年我的职业线路的变化,以及写博客&公众号有什么收获,算是自己过去的一个总结,如果能有点共鸣和帮助就更好了。
最早关注我公众号读者朋友大概都是因为软件测试而结缘的。是的,我做了近 10 的软件测试工作,先后在 SIMcom、东软、京东商城、外企从事过功能&自动化&性能测试工作。
从功能测试入行开始,我慢慢地感受到编程不是开发的独门武功,它也是测试工程师的必备技能,只有具备良好的编码能力,才能去做自动化、Unittest、以及测试开发等工作。
当我做了自动化测试工程师,我又发现相对于“发现”问题,“解决”问题更令我愉悦。我开始梦想有机会能去做开发,这样不但可以提高自己的编程能力,另外开发、测试都懂也能为自己今后的职业发展找到更多可能性。
最终是因为有这样的机会+自己的主动+编码过得去,我从测试转到了开发。起初的艰难和压力都是我工作近 10 年来前所未有的,白天看代码、晚上看代码、周末看代码… 天天如此。经过了半年多的努力,才终于上岸,可以做 C/C++ 项目的 Bugfix 了。
也正是因为有开发、自动化、持续集成的经验,在团队需要一名 Build/Release 工程师的时候,我知道这就是我最适合的岗位,负责产品的自动化构建、发布、基础设施建设、CI/CD 以及提高研发效能的相关开发工作。
就这样我从 QA 到 DEV 到 DEVOPS。公众号的更名记录也记录了我的职业路线变化:
写作是一项长期收益远超短期收益的事情。
对于绝大多数人在短期内几乎不会有什么实质性的收益,还会花费大量的业余时间,妥妥的是用爱在发电。从金钱角度来衡量这件事,这是一件投入和产出完全不成比例的事情,很难坚持。
如果从长期来看,坚持写作一定会带来价值的,我总结有以五个方面的好处:
关于 Vagrant 的介绍,可以参看前一篇文章:什么是 Vagrant? Vagrant 和 VirtualBox 的区别
关于 Vagrant 的介绍,可以参看前一篇文章:什么是 Vagrant? Vagrant 和 VirtualBox 的区别
关于 Vagrant 被问到最多的问题:Vagrant 和 Docker 之间有什么区别。
如果不分场景的直接比对 Vagrant 和 Docker 是不恰当的。在一些简单场景中,它们的作用是重复的,但在更多场景中,它们是无法相互替代的。
那么什么情况下应该用 Vagrant,什么情况下用 Docker 呢?
所以如果你仅仅是想管理虚拟机,那么你应该使用 Vagrant;如果你想快速开发和部署应用,那么应该使用 Docker。
下面具体来说说为什么。
Go 是一种开源编程语言,可以轻松构建简单、可靠和高效的软件。
先问一个大多数人可能会忽略的问题:Google 的这门开源编程语言叫 Go 还是 Golang?还是两个都行?给你三秒钟想一下 …
Google 说:它叫 Go。之所以有人称它为 Golang 是由于之前的 Go 语言官网是 golang.org(因为 go.org 已经被别人用了),因此有人将 Golang 和 Go 混用了。
现在输入 golang.org 会直接跳转到 go.dev 这个网址,这也算是彻底给自家孩子正个名。
官网是这样介绍 Go 语言的:
今天,Go 被用于各种应用程序:
本篇分享在编写 Dockerfiles 和使用 Docker 时应遵循的一些最佳实践。篇幅较长,建议先收藏慢慢看,保证看完会很有收获。
Dockerfile 最佳实践
COPY
而不是 ADD
Python
包缓存到 Docker 主机上ENTRYPOINT
和 CMD
之间的区别HEALTHCHECK
Docker 镜像最佳实践
.dockerignore
文件利用多阶段构建的优势来创建更精简、更安全的Docker镜像。多阶段 Docker 构建(multi-stage builds)允许你将你的 Dockerfile 分成几个阶段。
例如,你可以有一个阶段用于编译和构建你的应用程序,然后可以复制到后续阶段。由于只有最后一个阶段被用来创建镜像,与构建应用程序相关的依赖关系和工具就会被丢弃,因此可以留下一个精简的、模块化的、可用于生产的镜像。
Web 开发示例:
工作十几年用过了不少显示器,从最初的 17寸,到后来的 23寸、27寸、32寸、再到现在的 34 寸,根据我自己的使用体验,来个主观推荐:
第一名,一个34寸曲面显示器
第二名,一个27寸 + 一个23寸的双屏组合
第三名,一个32寸 + 一个23寸的双屏组合
第三名,两个 23 寸的双屏组合(并列第三名)
以上这些屏幕推荐购买 2K 及以上的分辨率,1080p 的分辨率不推荐。
下面我就按照时间轴说说我用过的那些显示器。
最近实现了一个很有意思的 Workflow,就是通过 GitHub Actions 自动将每次最新发布的文章自动同步到我的 GitHub 首页。
就像这样在首页显示最近发布的博客文章。
要实现这样的工作流需要了解以下这几点:
README.md
信息会显示在首页README.md
2021-22 世界质量报告(World Quality Report 简称 WQR)是由 Micro Focus,Capgemini 和 Sogeti 三家公司合作的来分析软件质量和测试趋势在全球范围内唯一的报告。
这份报告共采访了 1750 名高管和专业人士。从最高管理层到 QA 测试经理和质量工程师,涵盖了来自全球 32 个国家的 10 个行业。
世界质量报告(WQR)是一项独一无二的全球研究,今年的调查强调了新部署方法中不断变化的受大流行影响的应用程序需求的影响,以及 QA 对敏捷和 DevOps 实践的采用,AI 的持续增长。
作为测试关注这类软件质量报告可以帮助我们快速了解软件测试行业的现状和趋势。
WQR 的一个关键信息:在新冠疫情依旧的今天,我们看到了数字化转型的融合以及敏捷和 DevOps 实践的实时采用。此外,QA 正在成为采用敏捷和 DevOps 实践的领导者,为团队提供工具和流程以促进整个软件生命周期(SDLC)的质量。
WQR 围绕关键发现和趋势突出了五个特定主题:
这可能是中文网里介绍Polaris最详细的文章了
Polaris - 托管静态应用程序软件测试(SAST)工具的 SaaS 平台,它是用于分类和修复漏洞并运行报告的 Web 站点。
SAST - 一种对源代码分析或构建过程中去寻找安全漏洞的工具,是一种在软件开发的生命周期(SDLC)中确保安全的重要步骤。
Coverity - Coverity 是 Synopsys 公司提供的原始静态应用软件测试 (SAST) 工具。Polaris 是 Coverity 的 SaaS 版本。
Synopsys - 是开发 Polaris 和其他软件扫描工具的公司,比如 BlackDuck 也是他们的产品。
C/C++ |
通常如果你的组织引入了 Polaris 的 SaaS 服务,你将会有如下网址可供访问 URL: https://organization.polaris.synopsys.com
然后登录,你就可以给自己的 Git Repository 创建对应的项目了。
建议:创建的项目名称与 Git Repository 的名称一致。
在进行 Polaris 扫描之前,你需要先下载并安装 polaris。
如果你的 Polaris server URL 为:POLARIS_SERVER_URL=https://organization.polaris.synopsys.com
下载连接为:$POLARIS_SERVER_URL/api/tools/polaris_cli-linux64.zip
然后将下载到本地的 polaris_cli-linux64.zip
进行解压,将其 bin 目录添加到 PATH 中。
在进行扫描之前,你需要为你的项目创建 YAML 文件。默认配置文件名为 polaris.yml
,位于项目根目录。如果你希望指定不同的配置文件名,你可以在 polaris
命令中使用 -c
选项。
在项目根目录运行 polaris setup
以生成通用的 polaris.yml
文件。
运行 polaris configure
以确认你的文件在语法上是正确的并且 polaris
没有任何问题。
YAML 配置文件可以包含三种类型的 Capture:
Languages | Build Options |
---|---|
C, C++, ObjectiveC, Objective C++,Go, Scala, Swift | 使用 Build 捕获 |
PHP, Python, Ruby | 使用 Buildless 或 Filesystem 捕获 |
C#, Visual Basic. | 如果想获得更准确的结果使用 Build 捕获;如果寻求简单使用 Buildless 捕获 |
Java | 如果想获得更准确的结果使用 Build 捕获;如果寻求简单使用 Buildless 捕获 |
JavaScript,TypeScript | 使用 Filesystem 捕获;如果寻求简单使用 Buildless 捕获 |
如果你正在扫描 C/C++ 代码,则应包括此分析部分以充分利用 Polaris 的扫描功能:
analyze: |
After you have set up the SonarQube instance, you will need to integrate SonarQube with project.
Because I used the community edition version, it doesn’t support the C/C++ project, so I only demo how to integrate with Maven, Gradle, and Others.
For example, the demo project name and ID in SonarQube are both test-demo
, and I build with Jenkins.
When execute command: lcov --capture --directory . --no-external --output-file coverage.info
to generate code coverage report, I encountered the following error:
$ lcov --capture --directory . --no-external --output-file coverage.info |