2023 年最值得关注的 DevOps 趋势

DevOps 运动仍然是一个不断发展的领域,受到技术进步、行业趋势和组织需求等多种因素的影响。这使得很难对 DevOps 工程的未来做出具体预测。然而我认为有一些趋势可能会在来年继续影响 DevOps 领域的发展。

云原生技术的持续采用

容器化、微服务和无服务器计算等云原生技术会继续在 DevOps 环境中广泛采用,这些技术为各种项目提供了许多好处,包括:

  • 提高可扩展性和可靠性:云原生技术可以让 DevOps 团队更轻松地构建、部署和管理可扩展且有弹性的应用程序。
  • 更快的部署和迭代:云原生技术可以使团队更快地部署和迭代应用程序,帮助组织更快地行动并响应不断变化的业务需求。
  • 更大的灵活性和敏捷性:云原生技术可以为 DevOps 团队提供更大的灵活性和敏捷性,使他们能够使用各种工具和平台构建和部署应用程序。

总体而言,随着组织寻求提高数字时代的效率和竞争力,采用云原生技术可能会继续成为未来几年 DevOps 的趋势。 Kubernetes 和类似的编排平台仍将是这一过程的重要组成部分,因为它们为构建、部署和管理容器化提供了一致的、基于云的环境、应用程序和基础设施。

更加关注安全性和合规性

随着安全性和合规性的重要性不断增长,组织会更加重视将安全性和合规性最佳实践纳入其流程和工具中。

未来几年,安全性和合规性在一些特定领域尤为重要:

  • 云安全:随着越来越多的组织采用基于云的基础设施和服务,DevOps 团队将更加需要关注云安全性和合规性,包括确保云环境配置安全、数据在传输和静态时加密以及对云资源的访问进行控制和监控。
  • 应用程序安全性:DevOps 团队需要专注于构建安全的应用程序并确保它们以安全的方式进行测试和部署,包括实施安全编码实践、将安全测试纳入开发过程以及使用安全配置部署应用程序。
  • 遵守法规和标准:团队需要确保他们的流程和工具符合相关法规和行业标准,包括实施控制措施来保护敏感数据,确保系统配置为以合规的方式,通过审计和评估证明合规性,以及在适用的情况下将部分责任推给云提供商。

总而言之,随着组织寻求保护其系统、数据和客户免受网络威胁并确保遵守相关法规和标准,DevOps 中对安全性和合规性的关注肯定会增加,它还将使 DevSecOps 专家 在 DevOps 团队中发挥更大的作用。

开发和运营团队之间加强协作

DevOps 运动的理念是将开发和运营团队聚集在一起,以便更紧密、更有效地工作。未来几年,开发和运营团队之间的协作在一些关键领域可能会特别重要:

  • 持续集成和交付 (CI/CD):开发和运营团队需要密切合作,以确保有效地测试、部署和监控代码更改,并快速识别和解决任何问题。
  • 事件管理:开发和运营团队需要合作识别和解决生产环境中出现的问题,并制定策略以防止将来发生类似问题。
  • 容量规划和资源管理:开发和运营团队需要共同努力,以确保系统拥有必要的资源来满足需求,并规划未来的增长。

DevOps 的成功取决于开发和运营团队之间的强有力合作,这可能仍然是 2023 年的重点。

自动化和人工智能的持续发展

自动化和人工智能 (AI) 可能在 DevOps 的发展中发挥重要作用。自动化工具可以帮助 DevOps 团队对重复性任务进行编程、提高效率并降低人为错误的风险,而人工智能可用于分析数据、识别模式并协助做出更明智的决策。

  • 人工智能可能对 DevOps 产生重大影响的一个潜在领域是预测分析领域。通过分析过去部署和性能指标的数据,人工智能算法可以识别模式并预测未来的结果,从而使团队能够更好地优化其流程并提高整体性能。
  • 人工智能可能产生影响的另一个领域是事件管理领域。人工智能算法可用于分析日志数据并在潜在问题发生之前识别它们,从而使团队能够在出现重大事件之前主动解决出现的问题。

总体而言,DevOps 中自动化和人工智能的发展可能会带来更高效、更有效的流程,并提高应用程序和系统的性能和可靠性。然而,组织必须仔细考虑这些技术的潜在影响,并确保它们的使用方式符合其业务目标和价值观。
自动化和人工智能的实施应该成为战略的一部分:包括从一开始就需要集成到业务流程中,调整期望和目标,估计成本以及相关的风险和挑战。仅仅为了实现两者而实施并不一定会从中获益,相反,从长远来看,它可能会因维护它们而导致其他问题。

基础设施即代码的多云支持

基础设施即代码 (IaC) 正在成为一种越来越流行的实践,涉及使用与管理代码相同的版本控制和协作工具来管理基础设施。这使得组织能够将其基础设施视为一等公民,并且更容易自动化基础设施的配置和管理。

多云基础设施是指在单个组织内使用多个云计算平台,例如 AWS、Azure 和 Google Cloud。这种方法可以为组织提供更大的灵活性和弹性,因为它们不依赖于单个提供商。

结合这两个概念,对 IaC 的多云支持是指使用 IaC 实践和工具来管理和自动化跨多个云平台的资源调配和配置的能力。这可以包括使用 IaC 定义和部署基础设施资源,例如虚拟机、网络和存储,以及管理这些资源的配置。

使用 IaC 管理多云基础设施可以带来多种好处。它可以帮助组织在其环境中实现更高的一致性和标准化,并降低在多个云平台中管理资源的复杂性。它还可以使组织能够更轻松地在云平台之间迁移工作负载,并利用每个平台的独特功能。

总体而言,对于寻求优化多个云平台的使用并简化多云基础设施管理的组织来说,对 IaC 的多云支持可能仍然是一个重要因素。

更加强调多样性和包容性

随着技术行业继续关注多样性和包容性,DevOps 团队可能会更加重视建立多元化和包容性的团队并创造更具包容性的工作环境 - 包括:

  • 为团队提供具有新的非技术技能的人员,以填补深刻的技能差距。根据 《提高 IT 技能 2022》报告,IT 需要七种关键技能:流程和框架技能、人员技能、技术技能、自动化技能、领导技能、数字技能、业务技能和高级认知技能。不幸的是,大多数 IT 经理首先追求的是技术技能,而忽视了“软技能” —— 这可能是阻碍 DevOps 在组织中进一步发展的最大因素。
  • 整个团队以及单个 DevOps 成员的技能发展。近年来,每个人都面临着考验(新冠等流行病、不确定的经济形势),并使越来越多的 IT 专业人员不确定自己的技能,并感到需要进一步的培训和发展。与此同时,根据《2022 年 IT 技能提升》报告,接受调查的 IT 组织中只有 52% 制定了正式的技能提升计划。这实际上导致全球 IT 团队面临的最大挑战是缺乏技能。
  • 向外部团队开放,保证能力和预期质量的快速提高。无论是外包以及其他形式的合作。这还可以在优化生产成本方面带来切实的好处(这无疑是当今开展业务最重要的因素之一)。

概括

上述 6 个方面是我们认为 2023 年 DevOps 的主要趋势。当然,每个人都可以从自己的角度添加其他要点,例如:无服务器计算、低代码和无代码解决方案、GitOps 等。

过往 DevOps 趋势文章

参考


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

Upload artifacts failed to Artifactory from AIX

Recently my CI pipeline suddenly does not work on AIX 7.1 with error Caused by: javax.net.ssl.SSLHandshakeException: com.ibm.jsse2.util.h: PKIX path building failed: java.security.cert.CertPathBuilderException: PKIXCertPathBuilderImpl could not build a valid CertPath..

Click to see more details about the failure log.
22:13:30  Executing command: /bin/sh -c git log --pretty=format:%s -1
22:13:36 [consumer_0] Deploying artifact: https://artifactory.company.com/artifactory/generic-int-den/myproject/PRs/PR-880/1/myproject_bin_rel_AIX_5797b20.tar.Z
22:13:36 Error occurred for request GET /artifactory/api/system/version HTTP/1.1: com.ibm.jsse2.util.h: PKIX path building failed: java.security.cert.CertPathBuilderException: PKIXCertPathBuilderImpl could not build a valid CertPath.; internal cause is:
22:13:36 java.security.cert.CertPathValidatorException: The certificate issued by CN=DigiCert Global Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US is not trusted; internal cause is:
22:13:36 java.security.cert.CertPathValidatorException: Certificate chaining error.
22:13:36 Error occurred for request PUT /artifactory/generic-int-den/myproject/PRs/PR-880/1/cpplinter_bin_rel_AIX_5797b20.tar.Z;build.timestamp=1693273923987;build.name=PR-880;build.number=1 HTTP/1.1: com.ibm.jsse2.util.h: PKIX path building failed: java.security.cert.CertPathBuilderException: PKIXCertPathBuilderImpl could not build a valid CertPath.; internal cause is:
22:13:36 java.security.cert.CertPathValidatorException: The certificate issued by CN=DigiCert Global Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US is not trusted; internal cause is:
22:13:36 java.security.cert.CertPathValidatorException: Certificate chaining error.
22:13:36 [consumer_0] An exception occurred during execution:
22:13:36 java.lang.RuntimeException: javax.net.ssl.SSLHandshakeException: com.ibm.jsse2.util.h: PKIX path building failed: java.security.cert.CertPathBuilderException: PKIXCertPathBuilderImpl could not build a valid CertPath.; internal cause is:
22:13:36 java.security.cert.CertPathValidatorException: The certificate issued by CN=DigiCert Global Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US is not trusted; internal cause is:
22:13:36 java.security.cert.CertPathValidatorException: Certificate chaining error
22:13:36 at org.jfrog.build.extractor.clientConfiguration.util.spec.SpecDeploymentConsumer.consumerRun(SpecDeploymentConsumer.java:44)
22:13:36 at org.jfrog.build.extractor.producerConsumer.ConsumerRunnableBase.run(ConsumerRunnableBase.java:11)
22:13:36 at java.lang.Thread.run(Thread.java:785)
22:13:36 Caused by: javax.net.ssl.SSLHandshakeException: com.ibm.jsse2.util.h: PKIX path building failed: java.security.cert.CertPathBuilderException: PKIXCertPathBuilderImpl could not build a valid CertPath.; internal cause is:
22:13:36 java.security.cert.CertPathValidatorException: The certificate issued by CN=DigiCert Global Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US is not trusted; internal cause is:
22:13:36 java.security.cert.CertPathValidatorException: Certificate chaining error
22:13:36 at com.ibm.jsse2.j.a(j.java:3)
22:13:36 at com.ibm.jsse2.as.a(as.java:213)
22:13:36 at com.ibm.jsse2.C.a(C.java:339)
22:13:36 at com.ibm.jsse2.C.a(C.java:248)
22:13:36 at com.ibm.jsse2.D.a(D.java:291)
22:13:36 at com.ibm.jsse2.D.a(D.java:217)
22:13:36 at com.ibm.jsse2.C.r(C.java:373)
22:13:36 at com.ibm.jsse2.C.a(C.java:352)
22:13:36 at com.ibm.jsse2.as.a(as.java:752)
22:13:36 at com.ibm.jsse2.as.i(as.java:338)
22:13:36 at com.ibm.jsse2.as.a(as.java:711)
22:13:36 at com.ibm.jsse2.as.startHandshake(as.java:454)
22:13:36 at org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket(SSLConnectionSocketFactory.java:436)
22:13:36 at org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:384)
22:13:36 at org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:142)
22:13:36 at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:376)
22:13:36 at org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:393)
22:13:36 at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:236)
22:13:36 at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:186)
22:13:36 at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89)
22:13:36 at org.apache.http.impl.execchain.ServiceUnavailableRetryExec.execute(ServiceUnavailableRetryExec.java:85)
22:13:36 at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
22:13:36 at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185)
22:13:36 at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83)
22:13:36 at org.jfrog.build.client.PreemptiveHttpClient.execute(PreemptiveHttpClient.java:76)
22:13:36 at org.jfrog.build.client.PreemptiveHttpClient.execute(PreemptiveHttpClient.java:64)
22:13:36 at org.jfrog.build.client.JFrogHttpClient.sendRequest(JFrogHttpClient.java:133)
22:13:36 at org.jfrog.build.extractor.clientConfiguration.client.JFrogService.execute(JFrogService.java:112)
22:13:36 at org.jfrog.build.extractor.clientConfiguration.client.artifactory.services.Upload.execute(Upload.java:77)
22:13:36 at org.jfrog.build.extractor.clientConfiguration.client.artifactory.ArtifactoryManager.upload(ArtifactoryManager.java:267)
22:13:36 at org.jfrog.build.extractor.clientConfiguration.client.artifactory.ArtifactoryManager.upload(ArtifactoryManager.java:262)
22:13:36 at org.jfrog.build.extractor.clientConfiguration.util.spec.SpecDeploymentConsumer.consumerRun(SpecDeploymentConsumer.java:39)
22:13:36 ... 2 more
22:13:36 Caused by: com.ibm.jsse2.util.h: PKIX path building failed: java.security.cert.CertPathBuilderException: PKIXCertPathBuilderImpl could not build a valid CertPath.; internal cause is:
22:13:36 java.security.cert.CertPathValidatorException: The certificate issued by CN=DigiCert Global Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US is not trusted; internal cause is:
22:13:36 java.security.cert.CertPathValidatorException: Certificate chaining error
22:13:36 at com.ibm.jsse2.util.f.a(f.java:107)
22:13:36 at com.ibm.jsse2.util.f.b(f.java:143)
22:13:36 at com.ibm.jsse2.util.e.a(e.java:6)
22:13:36 at com.ibm.jsse2.aA.a(aA.java:99)
22:13:36 at com.ibm.jsse2.aA.a(aA.java:112)
22:13:36 at com.ibm.jsse2.aA.checkServerTrusted(aA.java:28)
22:13:36 at com.ibm.jsse2.D.a(D.java:588)
22:13:36 ... 29 more
22:13:36 Caused by: java.security.cert.CertPathBuilderException: PKIXCertPathBuilderImpl could not build a valid CertPath.; internal cause is:
22:13:36 java.security.cert.CertPathValidatorException: The certificate issued by CN=DigiCert Global Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US is not trusted; internal cause is:
22:13:36 java.security.cert.CertPathValidatorException: Certificate chaining error
22:13:36 at com.ibm.security.cert.PKIXCertPathBuilderImpl.engineBuild(PKIXCertPathBuilderImpl.java:422)
22:13:36 at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:268)
22:13:36 at com.ibm.jsse2.util.f.a(f.java:120)
22:13:36 ... 35 more
22:13:36 Caused by: java.security.cert.CertPathValidatorException: The certificate issued by CN=DigiCert Global Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US is not trusted; internal cause is:
22:13:36 java.security.cert.CertPathValidatorException: Certificate chaining error
22:13:36 at com.ibm.security.cert.BasicChecker.<init>(BasicChecker.java:111)
22:13:36 at com.ibm.security.cert.PKIXCertPathValidatorImpl.engineValidate(PKIXCertPathValidatorImpl.java:199)
22:13:36 at com.ibm.security.cert.PKIXCertPathBuilderImpl.myValidator(PKIXCertPathBuilderImpl.java:749)
22:13:36 at com.ibm.security.cert.PKIXCertPathBuilderImpl.buildCertPath(PKIXCertPathBuilderImpl.java:661)
22:13:36 at com.ibm.security.cert.PKIXCertPathBuilderImpl.buildCertPath(PKIXCertPathBuilderImpl.java:607)
22:13:36 at com.ibm.security.cert.PKIXCertPathBuilderImpl.engineBuild(PKIXCertPathBuilderImpl.java:368)
22:13:36 ... 37 more
22:13:36 Caused by: java.security.cert.CertPathValidatorException: Certificate chaining error
22:13:36 at com.ibm.security.cert.CertPathUtil.findIssuer(CertPathUtil.java:316)
22:13:36 at com.ibm.security.cert.BasicChecker.<init>(BasicChecker.java:108)
22:13:36 ... 42 more
22:13:36

I have tried to download certificate.pem from my Artifactory and run this command, but the issue still there on my AIX 7.3.

/usr/java8_64/jre/bin/keytool -importcert -alias cacertalias -keystore /usr/java8_64/jre/lib/security/cacerts -file /path/to/your/certificate.pem

It investing it can not reproduce on my Windows, Linux and AIX 7.3 build machines.

What’s the different between them? the only different is Java runtime. On my problematic AIX 7.1 build machine, I used a shared runtime which is a link to path /tools/AIX-7.1/Java8_64-8.0.0.401/usr/java8_64/bin/java

bash-5.0$ /tools/AIX-7.1/Java8_64-8.0.0.401/usr/java8_64/bin/java -version
java version "1.8.0"
Java(TM) SE Runtime Environment (build pap6480sr4fp1-20170215_01(SR4 FP1))
IBM J9 VM (build 2.8, JRE 1.8.0 AIX ppc64-64 Compressed References 20170209_336038 (JIT enabled, AOT enabled)
J9VM - R28_20170209_0201_B336038
JIT - tr.r14.java.green_20170125_131456
GC - R28_20170209_0201_B336038_CMPRSS
J9CL - 20170209_336038)
JCL - 20170215_01 based on Oracle jdk8u121-b13

And I have anther Java runtime installed my that machine which is /usr/java8_64/bin/java

bash-5.0$ /usr/java8_64/bin/java -version
java version "1.8.0_241"
Java(TM) SE Runtime Environment (build 8.0.6.5 - pap6480sr6fp5-20200111_02(SR6 FP5))
IBM J9 VM (build 2.9, JRE 1.8.0 AIX ppc64-64-Bit Compressed References 20200108_436782 (JIT enabled, AOT enabled)
OpenJ9 - 7d1059c
OMR - d059105
IBM - c8aee39)
JCL - 20200110_01 based on Oracle jdk8u241-b07

Actually the versions of these two java versions are different. I just changed configuration of JavaPath from /tools/AIX-7.1/Java8_64-8.0.0.401/usr/java8_64/bin/java to /usr/java8_64/bin/java in the Jenkins node and disconnect then launch agent again, it works.

I don’t why it works, I don’t know much about Java certificate, if you know the reason please leave comments and let me know. Thank you.


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

创建 NuGet Organization 的遇到的坑

其实创建包管理平台账户没什么可说的,但最近准备在 https://www.nuget.org 上面发布产品前创建 Organization 的时候确遇到了问题。

事情是这样的

作为一名公司员工在首次打开 NuGet 网站 (www.nuget.org) 的时候,点击【Sign in】,映入眼帘的就是【Sign in with Microsoft】,点击,下一步、下一步,我就顺利的就用公司邮箱注册了我的第一个 NuGet 的账户。

此时我准备创建一个 Organization 的时候,输入自己的公司邮箱提示这个邮箱地址已经被使用了,What ???

OK。那我就填写同事的公司邮箱地址吧。

同事在收到邮件通知后也是一步步操作,先是打开 NuGet.org,点击【Sign in with Microsoft】,然后也是需要填写自己的账户名,结果完成这一系列的操作之后,再输入他的邮件地址去注册 Organization 的时候也同样提示这个邮箱已经被使用了???什么操作!!!醉了…

如何解决的

就在这千钧一发焦急得等待发布之际,我突然灵机一动,以死马当活马医的心态,将我注册的 NuGet 的个人账户绑定的公司邮箱修改为了自己的 Gmail 邮箱,然后此时再去创建 Organization 的时候输入的是自己的公司邮箱,创建 Organization 成功了!!

好了,谨以此记录一下在注册 NuGet 时候遇到的问题。不知道对你是否有用,如果真的有帮助到你,举手示意一下哦。


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

Docker Buildx Bake:加速构建和管理多平台镜像的利器

随着容器化技术的普及和应用场景的增多,构建和管理多平台镜像变得越来越重要。Docker Buildx 是 Docker 官方对于 Docker CLI 的一个扩展,为 Docker 用户提供了更强大和灵活的构建功能。包括:

  1. 多平台构建:Docker Buildx 允许用户在一个构建命令中为多个不同的平台构建容器镜像。这样,你可以一次性构建适用于多种 CPU 架构的镜像,比如 x86、ARM 等,从而在不同的硬件设备上运行相同的镜像。
  2. 构建缓存优化:Docker Buildx 改进了构建过程中的缓存机制,通过自动识别 Dockerfile 中哪些部分是可缓存的,从而减少重复构建和加快构建速度。
  3. 并行构建:Buildx 允许并行构建多个镜像,提高了构建的效率。
  4. 多种输出格式:Buildx 支持不同的输出格式,包括 Docker 镜像、OCI 镜像、以及 rootfs 等。
  5. 构建策略:通过支持多种构建策略,用户可以更好地控制构建过程,例如,可以在多个节点上构建、使用远程构建等。

使用 docker buildx 需要 Docker Engine 版本不低于 19.03。

其中,Docker Buildx Bake 是 Buildx 的一个子命令,也是本篇文章要重点介绍包括概念、优势、使用场景以及如何使用该功能来加速构建和管理多平台镜像。

什么是 Docker Buildx Bake?

Docker Buildx Bake 是 Docker Buildx 的一项功能,它旨在简化和加速镜像构建过程。Bake 是一种声明式的构建定义方式,它允许用户在一个命令中定义多个构建配置和目标平台,实现自动化批量构建和发布跨平台镜像。

为什么使用 Docker Buildx Bake?

1. 提高构建效率

Bake 通过并行构建和缓存机制来提高构建效率。使用 Bake 可以一次性定义和构建多个镜像,而无需为每个镜像分别执行构建过程,这样可以大大节省构建时间,提高工作效率。

2. 支持多个平台和架构

Docker Buildx Bake 的另一个优势是它能够构建多个平台和架构的镜像。通过在 Bake 配置中指定不同的平台参数就可以轻松构建适用于不同操作系统和架构的镜像。这对于跨平台应用程序的开发和部署非常有用。

3. 一致的构建环境

通过 docker-bake.hcl (除了 HCL 配置文件之外还可以是 JSON 或是 YAML 文件)文件描述构建过程确保一致的构建环境,使不同的构建配置和目标平台之间具有相同的构建过程和结果。这种一致性有助于减少构建过程中的错误,而且构建配置更易于维护和管理。

如何使用 Docker Buildx Bake?

以下是使用 Docker Buildx Bake 进行高效构建的基本步骤,首先确保你已经安装了 Docker Engine 或 Docker Desktop 版本 19.03 以及以上。

然后你的 docker 命令将变成这样 docker buildx bake。以下 docker buildx bake --help 的帮助输出:

docker buildx bake --help

Usage: docker buildx bake [OPTIONS] [TARGET...]

Build from a file

Aliases:
docker buildx bake, docker buildx f

Options:
--builder string Override the configured builder instance
-f, --file stringArray Build definition file
--load Shorthand for "--set=*.output=type=docker"
--metadata-file string Write build result metadata to the file
--no-cache Do not use cache when building the image
--print Print the options without building
--progress string Set type of progress output ("auto", "plain", "tty"). Use plain to show container output (default "auto")
--provenance string Shorthand for "--set=*.attest=type=provenance"
--pull Always attempt to pull all referenced images
--push Shorthand for "--set=*.output=type=registry"
--sbom string Shorthand for "--set=*.attest=type=sbom"
--set stringArray Override target value (e.g., "targetpattern.key=value")

接下来尝试一下如何使用 docker buildx bake

1. 创建 Bake 配置文件

比如创建一个名为 docker-bake.dev.hcl 的 Bake 配置文件,并在其中定义构建上下文、目标平台和其他构建选项。以下是一个简单的示例:

# docker-bake.dev.hcl
group "default" {
targets = ["db", "webapp-dev"]
}

target "db" {
dockerfile = "Dockerfile.db"
tags = ["xianpengshen/docker-buildx-bake-demo:db"]
}

target "webapp-dev" {
dockerfile = "Dockerfile.webapp"
tags = ["xianpengshen/docker-buildx-bake-demo:webapp"]
}

target "webapp-release" {
inherits = ["webapp-dev"]
platforms = ["linux/amd64", "linux/arm64"]
}

2. 运行 Bake 构建

运行以下命令开始使用 Bake 构建镜像:

$ docker buildx bake -f docker-bake.dev.hcl db webapp-release

3. 打印构建选项

你还可以无需构建打印构建选项,使用用 --print 来查看某个目标构建是否符合预期。例如:

$ docker buildx bake -f docker-bake.dev.hcl --print db
[+] Building 0.0s (0/0)
{
"group": {
"default": {
"targets": [
"db"
]
}
},
"target": {
"db": {
"context": ".",
"dockerfile": "Dockerfile.db",
"tags": [
"xianpengshen/docker-buildx-bake-demo:db"
]
}
}
}

4. 发布构建镜像

通过添加 --push 选项可以将构建完成的镜像一键发布的镜像仓库,例如 $ docker buildx bake -f docker-bake.dev.hcl --push db webapp-release

以上示例中的 demo 放在这里了:https://github.com/shenxianpeng/docker-buildx-bake-demo

5. Buildx Bake 高级用法

Buildx Bake 还有其他更多的使用技巧,比如 variable, function , matrix 等这里就不一一介绍了,详情请参见官方 Buildx Bake reference 文档。

总结

Docker Buildx Bake 是一个功能强大的构建工具,它提供了一种简化和加速构建过程的方法。通过使用 Bake 你可以高效地构建和测试多个镜像,并且可以跨多个平台和架构进行构建。所以说 Bake 是开发人员和构建工程师的重要利器,掌握 Docker Buildx Bake 的使用方法将帮助你更好地应对多镜像构建的带来的挑战、加快应用程序的交付速度。


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

详解SBOM:定义、关系、区别、最佳实践和生成工具

什么是 SBOM

SBOM 是软件材料清单(Software Bill of Materials)的缩写。它是一份详细记录软件构建过程中使用的所有组件、库和依赖项的清单。

SBOM 类似于产品的配方清单,它列出了构成软件应用程序的各种元素,包括开源软件组件、第三方库、框架、工具等。每个元素在 SBOM 中都会有详细的信息,如名称、版本号、许可证信息、依赖关系等。

SBOM 的目的是增加软件供应链的可见性和透明度,并提供更好的风险管理和安全性。它可以帮助软件开发者、供应商和用户了解其软件中使用的组件和依赖项,以便更好地管理潜在的漏洞、安全风险和合规性问题。通过 SBOM 用户可以识别和跟踪软件中存在的任何潜在漏洞或已知的安全问题,并及时采取相应的补救措施。

SBOM 还可以用于软件审计、合规性要求和法规遵从性等方面。一些行业标准和法规(如软件供应链安全框架(SSCF)和欧盟网络和信息安全指令(NIS指令))已经要求软件供应商提供 SBOM,以提高软件供应链的安全性和可信度。

总之,SBOM 是一份记录软件构建过程中使用的所有组件和依赖项的清单,它提供了对软件供应链的可见性,有助于管理风险、提高安全性,并满足合规性要求。

SBOM 和 SLSA 之间有什么关系,两者的区别是什么

SBOM(软件材料清单)和 SLSA(Supply Chain Levels for Software Artifacts)是两个不同但相关的概念。

  • SBOM 是软件材料清单,它提供了对软件供应链的可见性,包括组件的版本、许可证信息、漏洞等。SBOM 旨在帮助组织更好地管理和控制软件供应链,识别和处理潜在的漏洞、合规性问题和安全风险。
  • SLSA 是一种供应链安全框架,它定义了不同级别的安全要求和实践,以确保软件供应链的安全性。SLSA 旨在加强软件的可信度和安全性,防止恶意代码、供应链攻击和漏洞的传播。SLSA 关注整个软件供应链的安全,包括组件的来源、验证、构建过程和发布机制。

关于两者的区别:

  1. 视角不同:SBOM 关注软件构建物料的清单和可见性,提供对组件和依赖项的详细信息。SLSA 关注供应链的安全性,定义了安全级别和实践,强调确保软件供应链的可信度和安全性。
  2. 用途不同:SBOM 用于识别和管理软件构建中的组件、漏洞和合规性问题。它提供了一种管理软件供应链风险的工具。SLSA 则提供了一种安全框架,通过定义安全级别和要求,帮助组织确保软件供应链的安全性。
  3. 关联性:SLSA 可以利用 SBOM 作为其实施的一部分。SBOM 提供了 SLSA 所需的组件和依赖项的详细信息,有助于验证和审计供应链的安全性。SLSA 的实践可以包括要求使用 SBOM 生成和验证,以确保软件供应链的可见性和完整性。

SBOM 和 SLSA 都是软件供应链安全中的两个关键概念。它们可以相互关联和互补使用,以加强软件供应链的安全性和管理。

SBOM 和 Black Duck 之间有什么区别

SBOM(Software Bill of Materials)和 Synopsys BlackDuck 是两个相关但不同的概念。下面是它们之间的区别:

SBOM:

  1. 定义:SBOM 是一种文档或清单,用于记录软件构建过程中使用的所有组件和依赖项。它提供了对软件供应链的可见性和透明度。
  2. 内容:SBOM 列出了每个组件的名称、版本号、作者、许可证信息等详细信息。它有助于追踪和管理软件的组件、依赖关系、漏洞和许可证合规性等。
  3. 用途:SBOM 用于软件供应链管理、安全审计、合规性验证和风险管理。它帮助组织了解软件构建中使用的组件,识别潜在的漏洞和风险,并确保合规性。

Synopsys Black Duck:

  1. 功能:Synopsys Black Duck 是一种供应链风险管理工具。它可以扫描软件项目,识别其中使用的开源组件和第三方库,并分析其许可证合规性、安全漏洞和其他潜在风险。
  2. 特点:Black Duck 具有广泛的漏洞数据库和许可证知识库,可与开发流程和 CI/CD 工具集成,提供漏洞警报、许可证合规报告和风险分析等功能。
  3. 目的:Black Duck 帮助组织管理和控制软件供应链风险,提供实时的开源组件和第三方库的安全和合规性信息,以支持决策和采取适当的措施。

综上所述,SBOM 是记录软件构建中使用的组件和依赖项,提供对软件供应链的可见性和管理。而 Black Duck 是一种供应链风险管理工具,通过扫描和分析软件项目中的开源组件和第三方库,提供许可证合规性、安全漏洞和风险分析等功能。Black Duck 可以用于生成 SBOM,并提供更全面的风险和合规性分析。因此,Black Duck 是一个具体的工具,而 SBOM 是一种记录和管理软件供应链信息的概念。

SBOM 的最佳实践

  1. 自动化生成:使用自动化工具生成 SBOM,避免手动创建和维护,确保准确性和一致性。
  2. 包含详细信息:在 SBOM 中包含尽可能详细的信息,如组件名称、版本号、作者、许可证信息、依赖关系、漏洞信息等。
  3. 定期更新:定期更新 SBOM 以反映最新的构建物料清单,确保其准确性和完整性。
  4. 版本控制:对于每个软件版本,建立和管理相应的 SBOM 版本,以便跟踪软件版本和其对应的构建物料清单。
  5. 集成到软件生命周期:将 SBOM 集成到整个软件生命周期中,包括开发、构建、测试、部署和维护阶段。
  6. 漏洞管理和风险评估:利用 SBOM 中的漏洞信息,与漏洞数据库集成,进行漏洞管理和风险评估。
  7. 供应商合作:与供应商和合作伙伴共享和获取 SBOM 信息,确保他们也提供准确的 SBOM,并持续关注他们的漏洞管理和合规性措施。

SBOM 的生成工具

  1. CycloneDX:CycloneDX 是一种开放的软件组件描述标准,用于生成和共享 SBOM。它支持多种语言和构建工具,具有广泛的生态系统和工具集成。
  2. SPDX:SPDX(Software Package Data Exchange)是一种开放的标准,用于描述软件组件和相关许可证信息。它提供了一种统一的方式来生成和交换SBOM。
  3. OWASP Dependency-Track:Dependency-Track 是一个开源的供应链安全平台,可生成和分析 SBOM,提供漏洞管理、许可证合规性和供应链可视化等功能。
  4. WhiteSource: WhiteSource 是一种供应链管理工具,提供了自动化的开源组件识别、许可证管理和漏洞分析,可以生成SBOM并进行风险评估。
  5. JFrog Xray:JFrog Xray 是一种软件供应链分析工具,可以扫描和分析构建物料清单,提供漏洞警报、许可证合规性和安全性分析。
  6. Microsoft sbom-tool:是一种高度可扩展、适用于企业的工具,可为各种工件创建 SPDX 2.2 兼容的 SBOM。
  7. trivy:支持在容器、Kubernetes、代码存储库、Cloud 等中查找漏洞、错误配置、密钥 和生成 SBOM。

除了以上这些还有一些其他工具也提供了 SBOM 生成、管理和分析的功能,你可以根据具体需求选择适合的工具来实施 SBOM 的最佳实践。

总结

希望通过这篇文章,让你了解了 SBOM 的概念、与 SLSA 和 Black Duck 的关系和区别、最佳实践以及可用的生成工具来帮助更好地管理软件供应链安全。

如果你是项目成员,是 Fork 原始仓库还是直接原始仓库中修改代码?

想必你也见到过很多开源项目中的 CONTRIBUTION.md 文档中通常都会让贡献者 Fork 仓库,然后做修改。

那么如果你是该开源项目中的成员是否需要 Fork 仓库进行修改呢?

以前我没有认真去想过这个问题,对于项目成员感觉 Fork 或不 Fork 好像差不多,但仔细想想 Fork 仓库与不 Fork 仓库其实是有以下几个主要的差别的:

修改权限

在原始仓库中,你可能没有直接修改代码的权限,当你 Fork 一个仓库时,会创建一个属于你自己的副本,你可以在这个副本中拥有完全的修改权限,你可以自由地进行更改、添加新功能、解决bug等,而不会对原始仓库产生直接影响。

做实验性的工作

如果你计划进行较大的修改或实验性工作,并且不希望直接影响原始仓库,那么 fork 仓库并在 fork 的中进行修改更为合适。

比如你需要实验性的去大量清理现有仓库里的一些垃圾文件或是代码,如果你需要需要多次尝试,并将多次修改直接 git push 到推送原始仓库进行保存或是测试,这大大增加原始仓库的存储空间,如果你的修改是大型文件,那么对原始仓库的存储空间影响则会更大;如果你是 Fork 仓库则不会造成原始仓库的影响,直到你完成修改通过 Pull Request 合并到原始仓库时才会产生新的存储空间。

代码审查和协作

当你 Fork 一个仓库并在自己的副本中进行修改后,你必须通过 Pull Request(PR)向原始仓库合并修改,有助于确保代码质量和功能正确性。(当然不 Fork 也可以这样做或不做,但 Fork 了就必须这样做了)

版本控制和历史记录

Fork 一个仓库后,你可以在自己的副本中维护独立的版本控制历史。你可以跟踪自己的更改、回溯历史、管理代码版本,而不会影响到原始仓库的版本控制。同时,你可以从原始仓库同步最新的更改,保持你的副本与原始仓库的同步。

总结

Fork 仓库与不 Fork 仓库的主要差别在于修改权限、做实验性的工作、代码审查和协作,以及版本控制和历史记录。

个人认为只要一个仓库的贡献者超过 3 人,都建议所有人都 Fork 原始仓库,通过 Pull Request 方式合并代码。

但也有例外情况可能不适合 Fork:项目在 Fork 之后 CI/CD 无法独立工作,但是你需要它们。比如 Fork 后的仓库因为环境等原因不支持独立的运行 CI/CD 而你需要在提交 Pull Request 之前通过自动化对分支进行测试。

另外还要为原始仓库需要做适当的分支权限设置,以防止就算两个人的团队另外一个人不熟悉 Git 使用了非常危险的操作,比如强制推送(Force Push),变基(Rebasing),强制检出(Force Checkout)可能导致代码丢失、数据损坏或版本控制问题。


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

程序员自我修养之Git提交信息和分支创建规范(工具篇)

Git 提交信息和 Git 分支命名规范是团队协作中非常重要的一部分,它们能够使代码库更加规范、易于维护和理解。

我们需要通过工具来帮助实现Git提交信息和分支创建规范,本篇将介绍如何使用 Commit Check 这个工具来验证提交信息、分支命名、提交用户名字、提交用户邮箱等是否符合规范。

更多关于Git提交信息和分支创建规范可以参看我之前发布的文章《程序员自我修养之Git提交信息和分支创建规范》,这里不再赘述。

Commit Check 简介

Commit Check 是一个可以检查 Git 提交信息,分支命名、提交者用户名、提交者邮箱等等。它是 Yet Another Commit Checker 的开源平替版。

Commit Check 的配置

使用默认设置

如果没有进行自定义设置,Commit Check 会使用默认设置。具体设置在此

默认设置中,提交信息遵循约定式提交,分支命名见分支模型详细信息

使用自定义配置

你可以在你的 Git 仓库下创建一个配置文件 .commit-check.yml 来自定义设置,例如:

checks:
- check: message
regex: '^(build|chore|ci|docs|feat|fix|perf|refactor|revert|style|test){1}(\([\w\-\.]+\))?(!)?: ([\w ])+([\s\S]*)|(Merge).*|(fixup!.*)'
error: "The commit message should be structured as follows:\n\n
<type>[optional scope]: <description>\n
[optional body]\n
[optional footer(s)]\n\n
More details please refer to https://www.conventionalcommits.org"
suggest: please check your commit message whether matches above regex
- check: branch
regex: ^(bugfix|feature|release|hotfix|task)\/.+|(master)|(main)|(HEAD)|(PR-.+)
error: "Branches must begin with these types: bugfix/ feature/ release/ hotfix/ task/"
suggest: run command `git checkout -b type/branch_name`
- check: author_name
regex: ^[A-Za-z ,.\'-]+$|.*(\[bot])
error: The committer name seems invalid
suggest: run command `git config user.name "Your Name"`
- check: author_email
regex: ^\S+@\S+\.\S+$
error: The committer email seems invalid
suggest: run command `git config user.email yourname@example.com`

你可以根据自己的需要来修改 regex, error, suggest 的值。

Commit Check 使用

Commit Check 支持多种使用方式

以 GitHub Action 来运行

例如创建一个 GitHub Action workflow 文件 .github/workflows/commit-check.yml

name: Commit Check

on:
push:
pull_request:
branches: 'main'

jobs:
commit-check:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- uses: commit-check/commit-check-action@v1
with:
message: true
branch: true
author-name: true
author-email: true
dry-run: true
job-summary: true

详细请参考 https://github.com/commit-check/commit-check-action

以 pre-commit hook 运行

首选需要安装了 pre-commit

然后将如下设置添加到你的 .pre-commit-config.yaml 文件中。

-   repo: https://github.com/commit-check/commit-check
rev: the tag or revision
hooks: # support hooks
- id: check-message
- id: check-branch
- id: check-author-name
- id: check-author-email

以命令行来运行

可以通过 pip 先安装

pip install commit-check

然后运行 commit-check --help 命令就可以查看如何使用了,具体可以参见文档

以 Git Hooks 来运行

要配置 Git Hooks ,你需要在 Git 存储库的 .git/hooks/ 目录中创建一个新的脚本文件。

例如 .git/hooks/pre-push,文件内容如下:

#!/bin/sh
commit-check --message --branch --author-name --author-email

并修改为可执行权限 chmod +x .git/hooks/pre-push,然后当你运行 git push 命令时,这个 push hook 会自动执行。

Commit Check 执行失败示例

检查提交信息失败

Commit rejected by Commit-Check.

(c).-.(c) (c).-.(c) (c).-.(c) (c).-.(c) (c).-.(c)
/ ._. \ / ._. \ / ._. \ / ._. \ / ._. \
__\( C )/__ __\( H )/__ __\( E )/__ __\( C )/__ __\( K )/__
(_.-/'-'\-._)(_.-/'-'\-._)(_.-/'-'\-._)(_.-/'-'\-._)(_.-/'-'\-._)
|| E || || R || || R || || O || || R ||
_.' '-' '._ _.' '-' '._ _.' '-' '._ _.' '-' '._ _.' '-' '._
(.-./`-´\.-.)(.-./`-´\.-.)(.-./`-´\.-.)(.-./`-´\.-.)(.-./`-´\.-.)
`-´ `-´ `-´ `-´ `-´ `-´ `-´ `-´ `-´ `-´

Invalid commit message => test
It doesn't match regex: ^(build|chore|ci|docs|feat|fix|perf|refactor|revert|style|test){1}(\([\w\-\.]+\))?(!)?: ([\w ])+([\s\S]*)

The commit message should be structured as follows:

<type>[optional scope]: <description>
[optional body]
[optional footer(s)]

More details please refer to https://www.conventionalcommits.org
Suggest: please check your commit message whether matches above regex

检查分支命名失败

Commit rejected by Commit-Check.

(c).-.(c) (c).-.(c) (c).-.(c) (c).-.(c) (c).-.(c)
/ ._. \ / ._. \ / ._. \ / ._. \ / ._. \
__\( C )/__ __\( H )/__ __\( E )/__ __\( C )/__ __\( K )/__
(_.-/'-'\-._)(_.-/'-'\-._)(_.-/'-'\-._)(_.-/'-'\-._)(_.-/'-'\-._)
|| E || || R || || R || || O || || R ||
_.' '-' '._ _.' '-' '._ _.' '-' '._ _.' '-' '._ _.' '-' '._
(.-./`-´\.-.)(.-./`-´\.-.)(.-./`-´\.-.)(.-./`-´\.-.)(.-./`-´\.-.)
`-´ `-´ `-´ `-´ `-´ `-´ `-´ `-´ `-´ `-´

Commit rejected.

Invalid branch name => test
It doesn't match regex: ^(bugfix|feature|release|hotfix|task)\/.+|(master)|(main)|(HEAD)|(PR-.+)

Branches must begin with these types: bugfix/ feature/ release/ hotfix/ task/
Suggest: run command `git checkout -b type/branch_name`

以上就是 Commit Check 的使用介绍了,更多新信息请参考 https://github.com/commit-check/commit-check


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

Jenkins agent service can not start automatically on Windows

What’s the issue

My Windows build machine is regular reboot after Windows updates, but my Jenkins agent service on this Windows can not
start automatically even I have set the startup type to Automatic.

Windows Service Config 2

Solution 1

After some research, select “Allow service to interact with desktop” with service properties on Log On tab can fix this problem.

In service properties -> Log On -> Select “Local System account” and select the checkbox for “Allow service to interact with desktop”.

Windows Service Config 2

Solution 2

Read More

SLSA 框架与软件供应链安全防护

随着近些年针对软件供应链发起的攻击次数越来越多,Google 发布了一系列指南来确保软件包的完整性,目的是为了防止未经授权的代码修改影响软件供应链。

Google 的 SLSA 框架(Supply-chain Levels for Software Artifacts 软件制品的供应链级别)是通过识别 CI/CD 流水线中的问题并减小影响,为实现更安全的软件开发和部署流程提供建议。

目录

  1. 什么是SLSA
  2. 软件供应链中的问题
    2.1 供应链攻击包括哪些
    2.2 真实世界的例子
  3. SLSA等级
    3.1 详细解释
    3.2 限制
  4. SLSA落地
  5. 其他工具

什么是SLSA

SLSA 全名是 Supply chain Levels for Software Artifacts, or SLSA (发音“salsa”).

SLSA 是一个端到端框架,一个标准和控制的清单确保软件构建和部署过程的安全性,防止篡改源代码、构建平台以及构件仓库而产生的威胁。

软件供应链中的问题

任何软件供应链都可能引入漏洞,随着系统变得越来越复杂,做好最佳实践从而保证交付工件的完整性变得非常重要。如果没有一定的规范和系统发展计划,就很难应对下一次黑客攻击。

供应链攻击包括哪些

Supply Chain Threats

A 提交未经认证的修改
B 泄露源码仓库
C 从被修改源代码构建
D 泄露构建过程
E 使用已泄露的依赖
F 上传被修改的包
G 泄露了包仓库
H 使用已泄露的包

真实世界的例子

完整性威胁 已知例子 SLSA 如何提供帮助
A 提交未经认证的修改 研究人员试图通过邮件列表上的
补丁程序故意将漏洞引入 Linux 内核。
两人审查发现了大部分(但不是全部)漏洞。
B 泄露源码仓库 PHP:攻击者破坏了 PHP 的自托管
git 服务器并注入了两个恶意提交。
一个受到更好保护的源代码平台
将成为攻击者更难攻击的目标。
C 从被修改源代码构建 Webmin:攻击者修改了构建基础设施
以使用与源代码控制不匹配的源文件。
符合 SLSA 标准的构建服务器会生成出处,
以识别实际使用的来源,从而使消费者能够检测到此类篡改。
D 泄露构建过程 SolarWinds:攻击者破坏了构建平台
并安装了在每次构建期间注入恶意行为的植入程序。
更高的 SLSA 级别需要对构建平台进行更强大的安全控制,
这使得妥协和获得持久性变得更加困难。
E 使用已泄露的依赖 event-stream:攻击者添加了一个无害的依赖项,然后更新了该依赖项
以添加恶意行为。更新与提交到 GitHub 的代码不匹配(即攻击 F)。
递归地将 SLSA 应用于所有依赖项会阻止这个特定的向量,因为
出处会表明它不是由适当的构建器构建的,或者源不是来自 GitHub。
F 上传被修改的包 CodeCov:攻击者使用泄露的凭据将恶意工件上传到
Google Cloud Storage(GCS),用户可以从中直接下载。
GCS 中工件的出处表明工件不是以
预期的方式从预期的源代码库中构建的。
G 泄露了包仓库 对包镜像的攻击:研究人员为几个流行的
包存储库运行镜像,这些镜像可能被用来提供恶意包。
与上面的 (F) 类似,恶意工件的来源表明它们不是
按预期构建的,也不是来自预期的源代码库。
H 使用已泄露的包 Browserify typosquatting:攻击者
上传了一个与原始名称相似的恶意包。
SLSA 不直接解决这种威胁,但将出处链接回源代码控制
可以启用和增强其他解决方案。

SLSA等级

Read More

如何在 DevOps 任务中使用 ChatGPT?

随着 DevOps 的流行,越来越多的开发团队正在寻找一些工具来帮助他们更好地完成任务。ChatGPT 是一款基于人工智能的自然语言处理工具,它可以用来帮助开发团队在 DevOps 任务中更加高效地工作。

本文将探讨如何在 DevOps 任务中使用 ChatGPT。

一、ChatGPT 简介

ChatGPT 是一款由 OpenAI 开发的人工智能自然语言处理工具。它可以用于许多不同的应用程序,例如语音识别、自然语言处理、文本生成等。
ChatGPT 使用深度学习技术,可以生成与输入内容相关的文本。它是一款非常强大的工具,可以帮助开发团队更加高效地工作。

二、ChatGPT 在 DevOps 中的应用

在 DevOps 中,开发团队通常需要快速解决问题,并与团队成员和客户进行有效沟通。ChatGPT 可以用来帮助解决这些问题。

  1. 自动化代码审查
    开发团队通常需要花费大量时间来进行代码审查。ChatGPT 可以用来自动化这个过程。它可以根据代码库中的样本代码,生成与样本代码风格相似的代码,并对新代码进行审查。这可以帮助开发团队更快地进行代码审查,并减少人为错误的可能性。

  2. 自动化测试
    测试是 DevOps 中不可或缺的一部分。ChatGPT 可以用来自动化测试。它可以根据测试用例生成相应的测试代码,并对测试结果进行评估。这可以帮助开发团队更快地进行测试,并减少人为错误的可能性。

  3. 自动化部署
    部署是 DevOps 中不可或缺的一部分。ChatGPT 可以用来自动化部署。它可以根据部署规则生成相应的部署代码,并对部署结果进行评估。这可以帮助开发团队更快地进行部署,并减少人为错误的可能性。

  4. 自动化文档生成
    文档是 DevOps 中不可或缺的一部分。ChatGPT 可以用来自动化文档生成。它可以根据项目的代码库和测试用例生成相应的文档,并对文档的质量进行评估。这可以帮助开发团队更快地生成文档,并减少人为错误的可能性。

三、如何使用 ChatGPT

要使用 ChatGPT,开发团队需要进行以下步骤:

Read More