DevOps落地实践：BAT系列：代码托管：iCode vs TGit

最新推荐文章于 2024-02-06 15:52:36 发布
最新推荐文章于 2024-02-06 15:52:36 发布
阅读量8k 收藏 2
点赞数
分类专栏： # 自动化工具 # 理论基础 文章标签： DevOps iCode TGit
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/liumiaocn/article/details/77862165
版权
本文比较了百度效率云的iCode和腾讯云的TGit在DevOps中的代码托管应用。iCode提供代码管理、评审、扫描等功能，TGit强调基于Git的在线托管，包括权限管理、代码历史等。两者均集成于各自云平台，提供附加服务，各有特色，如iCode的代码检索和TGit的加密存储。
摘要由CSDN通过智能技术生成

这里写图片描述

百度效率云

百度效率云是专业、好用的互联网软件研发平台。内嵌产品规划、开发计划、执行跟踪、回顾分析、持续改进等众多优秀管理实践，以及Git代码管理、代码评审、代码扫描、编译加速、持续集成、自动部署、自动测试等丰富优秀开发实践，为互联网软件研发团队提供开箱即用、全套、高效的工具装备。

腾讯云的DevOps

历经腾讯各业务线打磨，快速提升企业客户研发效率，降低研发成本.

代码托管

百度效率云，将自身定位为研发工具的SaaS解决方面，三大看点代码托管/CICD/敏捷看板非常清晰，对应icode/ipipe/icafe三大自研工具。而腾讯的DevOps解决方案聚焦于代码托管/CICD/测试管理/运维监控/项目管理五大领域，具体则依托于腾云TGit/CCI/COC/TAPD四大开发者工具。因为功能和做法较为相近，这篇文章中我们将会通过其官方的介绍来看一下代码托管的具体做法和各自的亮点。

TGit

TGit 代码托管
为开发者提供基于 Git 的在线代码托管工具，包含代码提交/存储/下载/复刻/分支/历史/比对/合并等功能。可一站式完成对代码及代码质量管理，项目及项目人员管理，

最低0.47元/天 解锁文章
淼叔
关注
专栏目录
DevOps落地实践：BAT系列：CICD：iPipe vs CCI
知行合一 止于至善
09-07 1万+
百度效率云，将自身定位为研发工具的SaaS解决方面，三大看点代码托管/CICD/敏捷看板非常清晰，对应icode/ipipe/icafe三大自研工具。而腾讯的DevOps解决方案聚焦于代码托管/CICD/测试管理/运维监控/项目管理五大领域，具体则依托于腾云TGit/CCI/COC/TAPD四大开发者工具。因为功能和做法较为相近，这篇文章中我们将会通过其官方的介绍来看一下CICD的具体做法和各自的亮点。
流程图
Connie1451的博客
02-13 259
程序流程图，用图像的方式表示程序的过程   各种符号的定义： 为便于识别，绘制流程图的习惯做法是： 圆角矩形表示“开始”与“结束”； 矩形表示行动方案、普通工作环节用； 菱形表示问题判断或判定（审核/审批/评审）环节； 用平行四边形表示输入输出； 箭头代表工作流方向。     例如 流程图画图思想参考： https://www.jianshu.com/p/874e71...
iCode代码托管的一些基本指令
Just code it!
05-04 5997
1、安装git客户端。2、提交代码：方式一：克隆新建的代码库，提交一段代码a）git clone + 地址  scp -p ... （克隆并安装hook）b）ls(找到当前目录，创建文件BCLOUD，就可以在里面写程序了，也可以直接echo'...'>创建的文件名字)c）git add BCLOUDd）git commit -m "add BCLOUD for first commit" (...
DevOps落地笔记-16|案例分析：百度效率云是如何做代码审查的
最新发布
u013699308的博客
02-06 1122
iCode是基于开源代码评审工具 Gerrit 的代码托管平台，也是采用的 Change Request 机制，当开发人员提交代码后，就会触发 iCode 内置的代码检查和流水线检查，最大程度的保证代码入库的质量。当团队对提交代码的质量有严格要求时，需通过开启代码评审，进行代码检查，来控制提交代码的质量。该模型可以有效管控提交代码的质量，因为每次提交都会生成一个 Code Review，如果代码变更存在问题，那么此次变更就不会合入代码库中，根本不会影响到代码库中的代码。合入后，评审的状态显示为“已合入”。
【DevOps研发管理方案】三：代码管理
夢的点滴的博客
09-30 1932
使用Git/SVN等开源版本控制系统进行代码托管。
1.STM32基本知识
qq_51021850的博客
04-08 2118
启动方式 常用的为第一种启动方式 除内核之外的部件被称为核外外设或片上外设，如：GPIO、USART （串口）、I2C、SPI等都叫片上外设 1. ICode 总线 ICode 中的 I 表示 Instruction，即指令。我们写好的程序编译之后都是一条条指令，存 放在 FLASH 中，内核要读取这些指令来执行程序就必须通过 ICode 总线，它几乎每时每刻 都需要被使用，它是专门用来取指的。 2、DCode 总线 DCode 中的 D 表示 Data，即数据，那说明这条总线是用来取数的。我们在写..
DevOps落地实践：BAT系列：敏捷看板：iCafe vs Tapd
知行合一 止于至善
09-07 9783
百度效率云，将自身定位为研发工具的SaaS解决方面，三大看点代码托管/CICD/敏捷看板非常清晰，对应icode/ipipe/icafe三大自研工具。而腾讯的DevOps解决方案聚焦于代码托管/CICD/测试管理/运维监控/项目管理五大领域，具体则依托于腾云TGit/CCI/COC/TAPD四大开发者工具。因为功能和做法较为相近，这篇文章中我们将会通过其官方的介绍来看一下敏捷看板的项目管理相关的做法
DevOps落地实践：BAT系列：云端运维：COC & BLUEKING
知行合一 止于至善
09-07 7634
目前国内很多平台提供的功能尚集中于Dev侧，而腾讯除了传统的Dev侧的功能提供，同时也给出了一些云端运维的产品，比如COC和BLUEKING。
DevOps落地实践：BAT系列：ALI：企业研发效能解决方案
知行合一 止于至善
09-05 6715
BAT相关的DevOps解决方案或者产品到底有哪些功能，各自有哪些优势，着眼点和客户场景是什么，我们通过目前各自官方公布的相关信息来简单一探究竟。首先来看一下ALI的DevOps解决方案
DevOps-版本控制进阶
05-08
刚刚发布的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测试，那太好了，现在是考虑您是否准备好实施持续交付的时候了。
Git学习
weixin_42887772的博客
12-01 553
Github作为最大的代码托管平台，是基于Git开发的Git是最优秀的版本控制工具iCode是基于Git的代码托管平台：是对软件开发过程中各种程序代码，配置文件，说明文档等。：集中式、分布式。
DevOps—源码管理工具Gitlab
weixin_37648525的博客
10-07 1755
在自动化构建的过程中，总是需要将我们开发的应用的源码拉取到服务器中进行生成、发布、测试操作，之后再推送到目标服务器上进行部署应用。这就需要我们拥有一个在线保存开发过程中的源代码的地方，也就是源代码管理服务器。GitLab 是一个开源的源代码管理应用，支持私有化部署安装，对于 GitLab 大家都应该很熟悉，就算大家实际工作中不涉及 DevOps 相关技术，没有用过 GitLab，相信也必然用过类似的工具，开发团队协助中一个源代码管理工具必然是必不可少的。，各种文档请参考官网。
【工具使用】git使用--将本地代码上传到icode代码库踩坑总结
weixin_37956114的博客
02-22 360
git使用–将本地代码上传到icode代码库踩坑总结\ 注意：代码库提交之前要先pull远端代码库！！！保持本地代码库与远端相同 tips: 想要合并入哪个分支，就checkout到哪个分支，执行merge 推送相关 我们对Markdown编辑器进行了一些功能拓展与语法支持，除了标准的Markdown编辑器功能，我们增加了如下几点新功能，帮助你用它写博客： 全新的界面设计 ，将会带来全新的写作体验； 在创作中心设置你喜爱的代码高亮样式，Markdown 将代码片显示选择的高亮样式 进行展示； 增加了 图
【转】DevOps的前世今生
星辰大海，脚踏实地
09-19 3272
DevOps一词的来自于Development和Operations的组合，突出重视软件开发人员和运维人员的沟通合作，通过自动化流程来使得软件构建、测试、发布更加快捷、频繁和可靠。
Cortex-M3 I-Code,D-Code,系统总线及其他总线接口
热门推荐
weixin_42672920的博客
06-12 1万+
Cortex-M3 的总线接口 下图是Cortex-M3的连接方式样板图，大家可以根据需求自行更改， CM3 处理器的总线接口是基于 AHB-Lite 和 APB 协议。下图中总线复用器的作用是，让指令和数据在同一个总线上传输的方式，因为代码存储区既可以由指令指令总线(I-Code)访问（取指时），也可以被数据总线（D-Code）访问（访问数据时），需要在中间插入一个总线开关，称为总线矩阵，或者使用一个AHB总线复用器。（这里所讲的总线矩阵不是 CM3 内部的总线矩阵，它们是两码事。 CM3 内部的总线矩阵
DevOps的介绍及常见的几种工具
迷逝
06-19 5802
一、DevOps的介绍 DevOps是Development和Operations的组合 可以把DevOps看作开发（软件工程）、技术运营和质量保障（QA）三者的交集。传统的软件组织将开发、IT运营和质量保障设为各自分离的部门。在这种环境下如何采用新的开发方法（例如敏捷软件开发），这是一个重要的课题：按照从前的工作方式，开发和部署不需要IT支持或者QA深入的、跨部门的支持，而却需要极其紧密的多部门协作。然而DevOps考虑的还不止是软件部署。它是一套针对这几个部门间沟通与协作问题的流程和方法。 需要频繁交付
云效DevOps初体验-代码管理
weixin_46281101的博客
08-07 1313
阿里云云效是企业级一站式DevOps平台。 新云效DevOps产品矩阵,包含全新的“项目协作”“知识库”“ 代码管理”“测试管理”“流水线” “制品仓库”6大核心产品。 在云计算快速发展的今天，中国及全球各地的企业正在认识到DevOps可以助力软件开发速度加快，软件应用质量提升，更重要的是与业务目标更完美地结合。现今已有很多DevOps平台，今天来体验一下阿里家的一站式DevOps平台-云效。 在开发过程中，云效会自动保存代码到代码库中，方便debug时进行溯源。作为团队性应用平台，在代..
DevOps 分支 流程 git
oQiuQian的博客
03-30 1795
敏捷开发方法 分支开发流程 对应软件过程简单说明 新需求应该有简单的需求文档 开发应该有设计方案（简单的用图说明即可，比如uml图） 测试要有测试用例，先跑冒烟，再跑详细的功能（牛的公司可以测试驱动开发，后台开发人员以跑通单元测试为目标） 发布上线应该配备上线方案，上线预案 各种评审环绕 ----- 开发者操作分支过程 1.本地分支一定和远程分支名字相同，并且关联起来。 比...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值