CI/CD——适合你吗?

目录

主要内容:CI/CD适合你吗?

你应该改变流程吗?

你应该考虑CI吗?

CD的优点和缺点

你应该考虑CI/CD吗?


序言:软件实践只有在特定环境中才是最好的

您是否曾与一位对新流程充满热情的演讲者一起参加过会议?他们相信每个人都应该使用这个过程。通常,我怀疑这个过程是否适合我的团队,但演示者似乎暗示我不完全理解他们试图传达的内容;也许我只需要开始尝试做出改变来实现它的价值。虽然这可能是真的,但多年来我了解到,许多人推销流程变更为他们的软件开发团队提供了巨大的价值回报,但他们推销的解决方案可能不适用于其他软件开发团队。演示者不会试图向我推销我不需要的东西,他们也不会不诚实,他们通常只是从单一上下文中考虑他们的解决方案。

我所说的上下文是什么意思?上下文是生产和部署软件的流程、人员、工具、网络、语言、部署模型和文化。在一种情况下最佳的实践在另一种情况下可能不是最佳的,就像建造房屋的最佳实践可能不同于建造桥梁或摩天大楼的最佳实践一样。上下文的某些方面比其他方面对某些最佳实践的影响更大。例如:

  • 您的部署模型是影响您选择的流程的一个方面。部署到Web应用程序时可以使用CI/CD流程,但在将软件部署到嵌入在飞机引擎中的芯片时则无法使用CI/CD
  • 对于所有成员都在同一地点并同时开始工作的Scrum团队来说,站立会议可能是理想的选择;但是对于坐在同一张桌子上进行mob编程的四人团队来说是浪费时间。

本系列文章将逐一介绍软件实践,以突出每种实践在哪些环境中可能运行良好,以及在哪些环境中该实践可能运行不佳,甚至可能适得其反。

扫描二维码关注公众号,回复: 13509037 查看本文章

这是上下文受限最佳实践的示例。大学毕业后,一名开发人员创建静态网站多年,修改html页面和JavaScript并将代码更改提交到GitHub,同时还维护Web服务器并使用FileZilla将文件更改上传到网站。但后来他发现Netlify使用JamStack流程,这使得将他的更改提交到GitHub并验证、编译、优化并自动部署到生产网站变得非常容易。现在他告诉每个人他们应该使用JamStackNetlify进行所有Web开发。如果他们正在部署静态公共网站,也许他们应该这样做。但是一些开发人员正在部署到内部网站。一些开发人员对其他团队的代码进行了数据库更改和依赖。一些开发人员的任务关键型应用程序不能因为生产错误而面临10秒停机的风险。这些是不同的上下文,Netlify/JamStack方法可能不适合这些上下文。

简而言之,任何最佳实践都适用于特定环境,不太可能适用于所有环境。我们需要确定可以应用于我们环境的最佳实践。有些人对他们关于最佳实践的想法持教条主义态度。他们相信一个过程应该始终适用于所有软件环境,但就个人而言,我认为可能没有最好的软件实践。我认为在很多情况下,某些流程建议都是糟糕的选择。

后续文章将一次检查一个过程,解释为什么在某些情况下这些过程是糟糕的选择。在某些情况下将被证明是糟糕选择的流程建议列表包括:ScrumTDD、结对编程、持续部署 (CD)、里程碑、速度、代码审查、回顾、目标管理 (MBO) ,和指标。

主要内容:CI/CD适合你吗?

首字母缩写词CI/CD代表持续集成持续交付以及持续部署。通常,也许总是,CI需要在任何一个CD可以实现之前实现。CI是指编码人员经常将代码更改推送到共享团队存储库,通常每天多次。在许多情况下,一旦推送到共享代码库完成,就会开始构建软件。在某些情况下,共享存储库的构建可能会定期(例如每小时)发生。自动化构建的好处是可以快速识别两个开发人员所做的代码更改相互冲突的情况。

除了运行构建之外,许多CI管道还对代码执行其他任务。这些任务包括静态代码分析又名“linting”,以确定代码是否遵循代码格式标准和命名约定,以及检查代码是否存在逻辑错误和造成安全漏洞的错误。静态代码分析可以检测是否引入了新的和未经批准的第三方库,或者代码复杂度级别是否超过了容忍级别,或者仅仅是一种方法中的代码行数是否超过了公司标准所批准的行数。如果代码编译并通过静态代码分析检查,那么它可能会执行一组单元测试和集成测试,以验证应用程序中的现有逻辑没有被最新的代码更改破坏。

CI包含两种实践;频繁的代码推送和自动构建。频繁推送代码的一些好处包括:

  • 如果开发人员所做的更改与其他开发人员提交的内容相冲突,他们会更快地获得反馈。
  • 当开发人员使用的代码库更新并且对代码所做的更改次数较少时,基于共享存储库的构建与其他开发人员的更改发生冲突的可能性较小。
  • 当开发人员频繁签入时,审查其他开发人员的代码会更容易,因为要审查的代码更改可能会更少。
  • 由于代码审查花费的时间更少,它们会减少开发人员审查代码的流程。
  • 由于代码审查花费的时间更少,其他开发人员更愿意执行代码审查并且更愿意尽快完成。

自动化构建的一些好处包括:

  • 如果代码推送到共享存储库导致构建失败,则响应相对较快
  • 来自静态代码分析工具的相对较快的反馈以识别问题
  • 如果代码更改在应用程序中产生了错误,则单元测试和集成测试的反馈相对较快

CI对许多软件开发团队来说是非常有益和无价的,但它不一定适用于所有软件开发环境。一些可能从CI中获得很少价值的上下文包括:

  • 当项目中只有一个开发人员且不存在CI环境时
  • 当开发人员正在探索一种用于开发的新编程语言时。在这种情况下,设置CI所需的时间可能超过可能会被丢弃的东西的价值。
  • 当编码语言是脚本语言并且没有编译步骤时
  • 当团队当前没有自动构建并在其本地机器上创建其产品的编译版本以部署到生产时

你应该改变流程吗?

在评估像CI之类的任何过程是否适合您时,进行评估的最重要因素是:

  • 我(我们)花时间实现流程或实践是否值得?
  • 该过程会提高我们的产品质量吗?

如果流程没有提高质量,则意味着它没有减少错误或减少安全漏洞或提高应用程序性能;并且实现该流程所花费的时间比不实现该流程所节省的时间要多得多,那么您可能不应该实现它。

你应该考虑CI吗?

有了CI的这个定义和评估标准,我相信大多数开发团队应该考虑将CI实现到他们的开发过程中。

CD的优点和缺点

CI/CD的另一个方面是CDCD代表持续交付持续部署或两者。这两个术语都意味着成功的软件构建会自动推送到可以测试或使用的环境中,但有些团队更喜欢将交付用于非生产环境,并为生产环境保留部署。此外,一些团队在成功构建后并不会真正自动将软件部署到环境中。相反,部署到环境需要授权人员单击按钮才能继续。

CD的采用率低于CI,部分原因是CI通常是CD的先决条件,但主要是因为CD不是许多软件产品的良好部署策略。事实上,CD甚至无法用于嵌入到芯片上并放置在飞机、汽车、冰箱、火箭和许多其他设备中的软件。CD对于大多数桌面应用程序和通过应用程序商店交付到手机和其他设备的应用程序也不实用。CI/CD最有可能用于部署Web应用程序和Web API

持续交付到非生产环境的一些好处包括:

  • 它迫使您将所有内容编成法典。这意味着您需要弄清楚如何自动化和自动应用环境特定的配置值。您可能需要学习如何使用容器来简化部署、版本控制和自动化DevOps的所有方面,
  • 它创造了可能性。例如,一旦您花时间创建了一个管道,您的自动化构建可以流入部署环境,您就会发现现在可以轻松地针对测试环境自动执行渗透测试和压力测试,
  • 开发人员可以在部署环境中测试一些他们无法在开发人员环境中测试的更改(又名:适用于我的机器),例如:
    • 与应用程序中的线程行为相关的更改
    • 与同时使用应用程序的多个设备的用户相关的更改
    • 压力测试应用程序的可扩展性
    • 测试受OAuthTLS等安全机制影响的功能
  • 开发人员可以更快地将新功能引入功能环境,以造福他人。
  • 开发人员可以轻松部署到测试环境,而无需等待DevOps团队或IT团队为他们执行任务。
  • 创建一个全新的环境变得更加容易。也许您目前只有生产和测试。现在,如果所有部署部分都是自动化的,您可以相对轻松地添加QA环境或临时环境。

持续部署到生产环境的一些好处包括:

  • 开发人员可以更快地获得新功能和生产修复。这对于静态站点非常有价值。这是大多数JamStack站点的核心功能。
  • 开发人员无需等待DevOps团队或IT团队为他们执行任务即可进行部署。

持续交付到非生产环境的一些挑战包括:

  • 将更改应用到数据库与代码更改相协调
  • 当前正在进行的其他人的测试中断。
  • 当多个团队部署到共享测试环境并且某些更改取决于顺序时,确保正确的部署顺序

持续部署到生产环境的一些障碍包括:

  • 需要将软件烧录到物理芯片中
  • 需要通过应用商店发布软件
  • 在生产之前需要进行冗长的集成测试和/或手动测试,通常是因为需要确保软件是正确的,如果它用于让人们保持活力
  • 公司希望在客户与软件交互之前发现软件的任何问题。

你应该考虑CI/CD吗?

你应该采用CI/CD吗?这是你需要自己回答的问题。您不仅应该考虑CI/CD可能为您的开发过程带来的好处和价值,还应该始终考虑采用一个过程是否比您可以进行的其他更改更有价值。仅仅因为我们认识到实现特定更改的价值并不意味着我们应该立即实现它。也许在实现CI/CD之前完成您正在从事的项目对您的公司更有价值。如果TeamCityOctopus Deploy是您正在考虑用于CI/CD的工具,那么等待六周的免费培训课程可能更有价值。也许您正在考虑从subversion迁移到git。如果是这样,您可能应该在构建CI/CD解决方案之前进行更改,否则你可能需要完全重建你的CI/CD管道。此外,从手动构建到CI/CD不太可能在短时间内完成。随着时间的推移,您将逐步实现和采用更多方面的东西。

我相信大多数开发团队应该考虑在他们的开发过程中实现持续交付。生产的持续部署可能主要对部署静态网站的团队有价值,可能还有一些具有少量数据或不重要数据的站点。

https://www.codeproject.com/Articles/5307667/CI-CD-Is-It-Right-For-You

猜你喜欢

转载自blog.csdn.net/mzl87/article/details/121237581