每个DevOps团队必须拥有版本控制的3个原因

您的计算机上是否有诸如DocFinalFinalFinal1_2.pdf之类的文件 如果这样做,那么您可能已经了解了版本控制的基本价值。

版本控制

通过将每个版本保存为新的“最终”版本,而不是覆盖以前的最终版本,您不仅可以区分同一文档的不同版本,而且可以确保以前的版本不会永远丢失。

当然,在共享文件或与他人协作时,这不是可行的工作方式。 当然,它不是在任何类型的项目中编写,编辑或共享代码的一种选择,更不用说拥有许多贡献者的大型应用程序了。

那么,有哪些系统可以帮助我们与团队合作而不致于一路走失呢? 维护有组织的版本历史的具体价值是什么? 继续阅读!

版本控制系统(VCS)的基本原理

团队用来跟踪更改和不同代码版本的系统称为版本控制系统(VCS)。 就像其他任何东西一样,每个VCS都有其独特的功能,并具有自己的优点和缺点。 但是,有一些基础知识可以使VCS成为真正的VCS。

首先,他们应该保留对项目所做更改的长期历史,包括创建,删除,编辑等。 其中应包括作者,日期以及所做更改的所有注释。

除此之外,他们还应该有一个解决方案,用于将新的代码更改分支和合并到主项目中,以允许团队中多个成员的并发工作。 毕竟,这就是重点。 项目的主要代码库称为Trunk或简称为Main。 分支创建为可以合并到Main的独立工作流。

所有这些都支持项目中的可追溯性。 万一出问题了,回顾过去所做的更改并在出现错误和错误时将它们联系起来会更容易。 这就引出了下一个问题,为什么版本控制如此重要?

VCS对于DevOps至关重要的3个原因

1.避免现代容器化应用程序中的依赖性问题

微服务从本质上已经成为开发新应用程序的默认方法,并且越来越多的团队也在容器化整体应用程序。 随着这种趋势的发展,依赖问题已经成为可能影响或破坏项目的焦点。

任何类型的项目中,无论是否进行了容器化,依赖性始终是一个大问题。 依赖地狱,在Java中被亲切地称为JAR地狱,在多种语言的应用程序中很常见,并且自从早期编程时代就已经存在。 最终,构建新功能和修复错误的线性路径必定会与另一个团队或修补程序或许多其他事情对另一个功能的并行开发产生冲突。

对于DevOps,在快速移动和保持应用程序可靠性之间找到平衡至关重要。 这部分意味着培养可追溯性,获得对代码所做更改的可见性,并了解这些更改如何影响应用程序性能。 访问不同的代码迭代可以揭示新的更改在何处暴露了与代码其他部分冲突的依赖关系。

2.版本控制与更高的DevOps性能相关

2014年DevOps年度状态研究发现,“版本控制始终是性能的最高预测指标之一。” 表现最好的工程团队能够实现更高的吞吐量-部署频率提高了8倍,部署交付时间缩短了8000倍。

自从2014年获得这些原始发现以来,版本控制一直没有丧失其相对于性能的重要性。 去年,它又与持续交付工作流程的成功联系在一起,而后者又有助于提高IT性能。

是什么导致版本控制和高性能之间的高度相关? 嗯,这部分与更轻松地查看和理解代码部分更改如何在整个应用程序中引起问题的能力有关。 但是,它与VCS如何启用编码实践(例如持续集成)以及持续交付/部署等有关。

3.支持构建更可靠的应用程序

2014年的同一项研究发现,使用全面的版本控制系统构建的应用程序更可靠。 他们的变更失败率降低了50%,MTTR(问题解决时间)提高了12倍。

在高性能DevOps团队和可靠的应用程序之间建立联系并不困难。 在任何组织中,DevOps的作用都是促进成功发展,并且由于变更通常是失败的根源,因此人们将重点放在降低变更风险上。

尽管乍看起来似乎违反直觉,但第一步通常是更频繁地进行较小的更改(因此CI变得很流行)。 同样重要的是,在加速的工作流程中,更重要的是跟踪这些更改,以便每个人都在看同一件事,从而在发生故障时更容易进行故障排除。

用于版本控制的系统

版本控制系统的第一个版本(双关语意味)是并发版本系统(CVS) 。 它的创建是为了支持时间表相互冲突的小型开发人员团队之间的合作。 在证明该项目有用后,创作者于1986年向公众发布了该代码。

Apache Subversion(通常缩写为SVN)

Subversion是由CollabNet在2000年代初创建的,旨在解决错误并在原始CVS跟踪系统中添加一些缺失的功能。 从那时起,它就被Apache孵化器所采用,并成为他们的顶级项目。

像其前身一样,Subversion是一个集中式VCS,这意味着每个项目都有一个集中式副本,并且代码更改将提交给该集中式副本。 最大的缺点之一是,它阻止用户在脱机时提交代码更改。

吉特

今天最受欢迎的版本控制系统是Git。 这就是所谓的分布式VCS,这意味着没有单一的集中式代码库。 相反,不同的分支负责托管不同的代码段。 这有助于开发人员和工程师在本地和/或脱机环境中使用代码。

在这个领域,我们有一些流行的工具,例如:

  • 的GitHub
  • 比特桶
  • 亚搏体育app

查看这篇文章,以了解有关这些工具的更多信息,并且可能最适合您的工作流程。

另外,谨提一些荣誉:

  • 水银
  • 螺旋VCS
  • 市场

最后的想法

版本控制是一个基本概念,许多人自然会使用自己的个人文件来执行。 但是它的重要性,尤其是对于DevOps,不容忽视。 它与IT绩效直接相关,这对公司的收入和成功有明显的影响。

通过促进团队协作并启用对代码库的追溯检查,版本控制系统可帮助创建更可靠的代码并维护代码。

阅读有关流行的版本控制系统GitHub和BitBucket的更多信息,并找出最适合您的版本控制系统。

翻译自: https://www.javacodegeeks.com/2018/08/version-control-devops-team.html

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
刚刚发布的ThoughtWorks技术雷达 建议技术团队“暂缓或谨慎”使用反模式“CI theatre(伪CI,可以理解为不完整的持续集成)”。 “伪CI”描述的是实践持续集成(CI)过程中的一些错觉,然而这些并不是真正的CI实践。 基于持续集成,我和同事 Emily Luke做了一些研究, 我将分享伪CI是什么样的,为什么我们建议你“暂缓或谨慎使用”,以及预防伪CI的方法。持续集成我最喜欢的CI定义来自于continuousdelivery.comCI开发人员定期(至少每天)将他们所有的工作集成到主干(也称为主线或主干分支)这个引用中暗含了CI实践的两个基本原则。第一个是“把他们所有的工作集成到主干”;第二个是“至少每天”。对于CI还有一系列其他原则和实践,例如:将所有内容都检入您的代码库,构建每个提交,自动化构建,保持快速构建,并有可以自我验证的代码, 还有Martin Fowler 关于持续集成的评论中的可视化故障并立即修复故障等。我个人认为 每天至少检入代码到主干分支一次 是CI的基础。没有达到这一点就只是伪CI而不是真正意义上的CI。伪CI是什么样的?这是我们调研到的一个故事,一位经验丰富的开发人员(让我们称他为David)来自湾区的一个中型创业公司,每周有两次产品交付。 David说他的组织正在践行CI,他说:“是的,我们用Circle CI”,他描述了一个具有挑战性的场景,曾经在一个分支上工作了一段时间,大约修改了100个文件和7000行代码,然后在代码审查阶段就开始招架不住了,因为他要向他的同事解释所有的代码变更的原因。“最具挑战性的事情是你最终要将一大堆功能集中到一个提交里,因为它们都是这个组件的一部分”,他解释说:“我希望有一个更好的方式来分解这些提交,因为很难把所有事情(变更历史)记在脑子里。”如果这个情况你听起来很熟悉,那么你也在做伪CI。 如果有下面的这些场景,那么你们就是在做伪CI:当有人问起你们在实践CI吗? 如果你说我们有一个CI服务器并且我们使用X工具在我们的调查中,只有10%的参与者承认有CI服务器与CI践行不一样。 相反,90%的个人表示他们正在践行CI,无论他们是否有专门从事CI的基础知识。 所以简单的认为只要有一个CI服务器就是“在做CI”,这就清楚地表明是在做“伪CI”。使用长期开发分支,但不会定期检入master主干在David的故事中,他们并没有实践每天检入master主干,这就是“伪CI”的标志。 这是我们在调研中常看到的一种模式,其中团队在master主干上运行CI,但不频繁构建,也不是每天都在提交。 或者他们在分支上运行CI,但不会频繁的集成到master主干。 只对特性分支运行CI,其实应该称之为持续隔离(continuous isolation)才对.合并分支时感到焦虑和疲惫真正的持续集成要把代码所有者的责任意识扩展到整个团队。 这改变了团队内部人员的观点以及他们对失败构建的态度。 不再是“我的宝贵的分支”,或是“我的错误导致构建被破坏”,而是“我们的代码”和“我们的失败”。David遇到焦虑和疲惫的事实清楚地表明,他忽略了CI的一个重要的优势:持续反馈和代码集体所有权。伪CI还有更多的一些现象,虽然我们发现有一些并不那么常见,但它们仍然存在一些问题,构建的时候,仅有极少的测试覆盖允许构建长时间处于失败状态虽然David的团队引入了一个备受尊崇的CI工具和常见的流程,如特征分支和代码审查,但他们并没有实施全套CI实践,因此错过了许多好处。 我们遗憾的发现,在我们的研究的组织中90%发生了这种情况。一些组织实施伪CI中反而错失了CI的主要优势 - 快速反馈,代码集体所有权,并准备达成持续交付如何避免,预防和解决伪CI的问题?如果您确定可能正在遭受伪CI之苦,则可以通过三种方式来解决问题并进行持续改变。1. 提交更频繁回到根本,尽量频繁地提交,每天至少提交一次应该是最低目标。 如果你还没有开始做CI,这就是你可以开始的地方,即使你在做CI,依然会有改进的空间。我喜欢“频率降低难度”的说法。 往往我们在做一些事情时,任务变得越小,则其更容易被实现。 持续集成就是是一个典型例子。 我的建议是要更加频繁地检入你的代码到代码库并且将开发分支集成到主干分支,至少每天集成一次”。2. 基于主干分支开发有很多论坛在讨论基于主干还是基于开发分支进行开发,我不想讨论那些血淋淋的细节。 然而,在我们的调研中,当我们与一些曾经在实践CI过程中感到痛苦的人交谈时,没有引入主干开发的团队对此有更深刻的感受。 DevOps现状调查报告-2016 还发现,基于主干开发和持续集成是达成持续交付的关键因素,同时也能建设更高效能的团队。基于主干的开发肯定会有一定的挑战,但它可以把问题提前暴露出来,而不是要等到代码合并、代码审查甚至到延迟发布的时候。如果你想达到更好效果的CI和CD,我建议在主干上做开发,或者如果你更愿意使用短周期的临时分支(合并到主干之前不到一天)进行开发,那么最好同时不要超过三个以上的活跃分支。3. 自动化自动化是做好持续集成的基石,所以如果你还没有自动化一切,现在是开始的好时机。 如果你认为已经实现了所有自动化的功能,那么每次有人手动地做任何事情超过一次,便要问自己“这个为什么不能自动化”? 我已经观察到自动化不仅可以帮助您在CI中变得更好,还可以帮助您开始持续交付。总结现在你知道什么是伪CI了,如果你的团队正在这么实践伪CI,那么你可以阻止这种情况继续发生了。 如果您仍然感到困惑,我建议你在Martin Fowler的博客“CI Certification test”做一个测试, 以确认你的组织是否正在做可靠的CI。 如果你通过了CI测试,那太好了,现在是考虑您是否准备好实施持续交付的时候了。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值