打通 DevOps 任督二脉 ,CODING 2.0 制品库全新上线

CODING 在近期的 KubeCon 2019 大会上发布了 CODING 2.0,同时发布了最新功能——制品库。CODING 不断完善 DevOps 工具链,旨在持续提升研发组织软件交付的速度与质量。

什么是制品库

软件制品是指由源码编译打包生成的二进制文件,不同的开发语言对应着不同格式的二进制文件,这些二进制通常可以直接运行在服务器上。

图片

制品库用来统一管理不同格式的软件制品。 除了基本的存储功能,还提供了版本控制、访问控制、安全扫描、依赖分析等重要功能,是一种企业处理软件开发过程中产生的所有包类型的标准化方式。

制品库:DevOps 的枢纽中心

当下不少研发组织依然使用着粗粒度的制品管理(比如搭建简易 FTP 来提供制品下载 ),甚至没有进行基本的制品管理。在这种粗放式的制品管理方式下,不同类型包的存储与获取是一件头疼的事情,版本追踪极其混乱,团队协作也是障碍不少。

标准化的制品管理帮助企业组织解决上述困扰。在 DevOps 自动化流水线当中,持续集成的构建物自动存入制品库中,在部署时按需获取对应的版本,制品库让研发团队真正做到 deploy anytime anywhere。制品库给企业带来的好处还包括:

图片

  • 可追溯的版本控制

制品库当中存储了更加完善的元数据,包括每个制品的版本号是什么,哈希值式、构建时间、上传者、下载次数等,有助于确保制品的正确版本和来源始终可用且可验证。

  • 开箱即用的多类型包管理

不同的制品类型(Docker/Maven/NPM 等)对应着不同的上传、存储、获取方式。制品库提供开箱即用的私有制品库管理,用于存储不同类型的制品。

  • 高效有序的协作

团队各角色例如开发、测试、运维、CI/CD 人员,通过统一的制品库,按需获取版本(快照版本、测试版本以及稳定版本),减少不必要的沟通,增强团队内部协作。

  • 精细化的安全管控

研发组织可以按需设置制品库的开放程度,以及按需设置各成员的制品访问权限,提高企业数字资产保密性、安全性的同时,又保留一定的开放性。

制品库是 DevOps 当中的重要枢纽,是连接持续集成与持续交付的关键实践。它提高了开发人员的工作效率和协作,同时推动 DevOps 和持续交付目标。

CODING 制品库:无缝的部署交付,便捷的软件分发

CODING 制品库支持 Docker Image、Maven/Jar、Kubernetes Helm、Node.js NPM 包等常见制品类型。制品库可以跟源代码协同进行版本化控制,可以与本地各构建工具和云上的持续集成、持续部署无缝结合。企业可按需将制品库设置为企业内部公开、项目内部公开、外部公开。同时 CODING 在制品库支持类型、软件漏洞扫描、访问速度上都进行了深度优化,让企业用户享受更快、更可靠、更方便的标准化制品管理体验。接下来我们来看看这些具体的优化:

图片

  • 多种制品的类型支持

针对技术栈丰富的研发团队,CODING 制品库满足其单项目多类型制品的诉求,可实现同一个项目中既支持 Docker 镜像又支持 Maven/Jar 的制品存储。

  • 无缝衔接常见构建工具

制品库兼容所有常见的制品格式标准,开发者不用更换任何构建工具、安装任何其它本地软件或者插件,即可无缝使用。

  • 极速分发

支持公开仓库和私有仓库,依托腾讯云强大的 CDN 能力,团队可以在全球范围内安全地、极速畅享制品库上传和下载。

  • 漏洞扫描

存放在制品库的构建产物可以使用预先提供的镜像安全扫描功能,或自定义的安全扫描策略进行质检。

  • 上下游整合

不管是与上游的代码仓库版本匹配,还是与持续部署和运维系统的接口兼容,都提供了良好的适配接口,使得 DevOps 可以上下游一体化。

图片

制品库作为 CODING 提供的一站式 DevOps 解决方案当中重要的一环,为企业 DevOps 转型提供了更加完善的全链路工具,我们用每一次产品的迭代更新来践行“让开发更简单”。

点击下方,了解更多 CODING 2.0 升级资讯:
《CODING 2.0 企业级持续交付解决方案》
《CODING 2.0:为什么我们需要 DevOps》
《CODING 2.0 服务升级:一站式服务体系助力企业研发上云》
《CODING 2.0:如何通过设计给品牌创造价值?》

点击使用 CODING 2.0 
体验 DevOps 全工具链敏捷研发

转载于:https://www.cnblogs.com/codingdevops/p/11126933.html

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 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、付费专栏及课程。

余额充值