关于coding:如何让-300-万程序员爱上-CODING

《DNSPod十问》是由腾讯云企业核心推出的一档深度谈话栏目,通过每期向嘉宾提出十个问题,带着广大读者站在产业互联网、科技领域精英的肩膀上,鸟瞰各大行业发展趋势和前沿技术变革。 刘毅,腾讯云 CODING CEO、腾讯云开发者产品总经理。次要负责腾讯云开发者生态以及开发者工具和平台产品经营,率领团队把腾讯外部我的项目协同和研发效力晋升过程中,大规模利用到的工具和平台以及相干的优良实际输入和赋能给各行各业合作伙伴,帮忙实现数字化转型和降级。2011 年退出腾讯,打造过社交产品 QQ 空间,也打造过办公合作产品腾讯文档。 田超,腾讯云企业核心总经理、音视频利用平台总经理,负责腾讯云用户增长、DNSPod 业务以及企业应用相干产品。同时也是资深用户增长专家,大数据技术专家,曾任利用宝增长平台总经理,摩拜单车技术副总裁。长期致力于对企业数字化相干钻研。 1田超:Bati 算是互联网老兵了,2011 年退出腾讯,已经打造过社交产品 QQ 空间、办公合作产品腾讯文档,这两款产品都是腾讯的当家产品,面向的用户体量十分大,置信开发过程中产生了不少故事,过后有什么比拟难忘的经验吗? 刘毅:我刚退出腾讯时,正赶上挪动互联网大潮,很多产品都处于摸索阶段,去打造一款亿级用户体量的挪动社交利用 QQ 空间,的确是个十分大的挑战。从零搭建挪动平台上的基础设施,到产品体验的深耕细作,再到海量用户经营,咱们都投入了十分大的心血。 过后有两件比拟有挑战的事: 一、怎么在 2G 网络下保障通信链路可靠性和稳定性?尤其在 2G 到 3G 过渡的阶段,以及受到网络劫持的状况下,咱们做了大量的摸索和试验去保障 QQ 空间的失常运行。 二、国内当初司空见惯的美白美颜实时滤镜最后就是从 QQ 空间产品内推出的。 再起初做腾讯文档也十分具备挑战性。咱们把办公软件模式搬到云上,须要从底层的多人合作抵触算法开始钻研,同时合作人数从几百人到几万人,再到上百万人,外面深挖了十分多核心技术、建设和晋升了大量的经营、运维和工程能力。 印象最粗浅的不仅仅是腾讯文档成为全民皆知的在线协同办公产品,还在社会突发事件上为上万千民众及时提供了反对和帮忙,让人不禁感叹互联网产品奉献出的微小的社会价值。 2田超:你过往的经验比拟偏差 To C ,那么当初来到专门做 To B 的腾讯云,负责开发者工具和平台产品经营,你是如何适应这个转变的?以前的教训对当初的工作有什么能够借鉴的中央吗? 刘毅:To C 产品是十分重视用户体验的,“用户价值、用户为本”始终是咱们遵守的信条。To C 讲求对用户价值的深挖、对用户场景的把握、对产品体验的打磨,这些教训在 To B 同样能够复用。 恰好我负责的开发者工具产品和开发者生态平台须要亲密关注 C 端用户体验,从开发者日常场景登程,关注其用到的所有腾讯云云产品体验,帮忙腾讯云一直优化产品用户口碑,意义是十分重大的。 当然做 To B 也有不一样的中央,还须要关注各行各业运行的实质法则,深刻了解客户增收提效的实在需要,有针对性地设计解决方案,还要兼顾洽购者和使用者不同人群的诉求。 最初还有集体心态的转变,从生产互联网向产业互联网转变、由虚转实曾经是中国社会倒退的大势所趋,所以我本人很早就开始在业余能力、产业视线上做出调整。 3田超:CODING 是腾讯旗下一站式软件研发治理平台,自 2014 年来曾经上线运行 8 年,累积超过 300 万开发者用户,稳居国内研发工具畛域 TOP 。你认为比照友商,CODING 的外围劣势在哪里?CODING 如何在泛滥竞争对手的夹击中成为行业冠军? ...

May 20, 2023 · 2 min · jiezi

关于coding:专精特新-︱-腾讯云-CODING-助力消费电子类企业高速发展期的研运一体化

May 20, 2023 · 0 min · jiezi

关于coding:五大不良-coding-习惯你占了几样

在之前的文章中,咱们一起解读了2021年数据老本报告。依据 IBM 和 Ponemon Institute 2021年的报告,寰球均匀数据泄露老本约为424万美元。为了升高数据泄露造成的老本,企业能够通过多种形式积极主动地爱护数据安全。而平安编码(Secure Coding)自身不须要任何老本,这是企业可能且该当采纳的一种安全措施。 通过进步对不良编码习惯(Bad Coding Habits)的认知,企业能够开始被动关注代码的完整性。 什么是平安编码?平安编码通过对编写代码过程的严格把控,来被动应答潜在的安全漏洞。然而平安编码不仅仅只是编写好代码,而是在平安的环境中,在平安的平台上进行开发。当然在云计算时代,平台和软件等服务都须要正确配置。 为什么平安编码很重要?不难理解,不平安的编码会造成平安危险,尤其是数据泄露危险。当企业面临重大安全漏洞时,他们并不会总是披露安全漏洞的性质。这是因为即便企业晓得是什么起因造成的,并且及时修复了破绽,然而对于这些破绽修复信息对于潜在的歹意攻击者来说依然具备很高的参考价值。 数据泄露可能是最可怕且代价最大的安全漏洞。在 IBM 和 Ponemon Institute 的钻研中,44% 的泄露事件中蕴含了客户个人身份信息(Personal Identifiable Information, PII)。每条客户 PII 记录的均匀老本高达 180 美元。因而企业须要增强平安协定,而平安编码是这些平安协定的外围。换句话来说,如果没有平安编码,所有平安协定都无奈爱护企业最有价值的资产。 5大不良编码习惯本文咱们将着重解说开发人员在从业晚期的一些不良编码习惯行为,这些行为如果不进行及时纠正和管制,可能会造成重大的平安为题。因而,企业须要确保所有开发人员对这些不良coding行为和习惯有明确的认知,并学习如何防止这些行为呈现在开发过程中。 1. 未查看复制的代码有时开发须要一些外围性能,而正好有其余的开发人员曾经对此进行屡次编码,这时复制代码是一个省时省力的动作。 理解你所复制的代码,就好比查看共事的代码一样,请确保在复制代码前曾经通读并充沛了解。永远不要自觉置信互联网上的某个人公开的代码,切记检查和核实。 尽可能应用库(library)。在某种程度上,应用库要比复制代码更保险一些。当然开发人员也须要依据本身需要来决定。如果须要一些字符串解决性能,那么应用对应的解决字符串的库可能对我的项目来说是一个很好的补充。而如果只须要一个函数,那么简略的复制可能比应用整个库更加便捷。 2. 已弃用、废除和可疑的库在已弃用、废除和可疑的库中有很多不良代码。有时开源代码在未经社区适当审查的状况下被打包到库中,而这可能导致代码中存在安全漏洞。这些安全漏洞没有人违心去被动辨认,更不用说去修复了。 因而,应用库时肯定要确保这些库时受信赖的企业或大量开发人员宽泛应用和监控的库,这些库可能失去保护和定期更新。假如这个库十年没有更新,那么开发人员首先要思考是否持续应用该库,或者在将其合并到我的项目之前先查看整个代码库。切忌自觉置信和应用。 3. 不受限制的存储库拜访在当今开发环境中,大家偏向于置信开发人员能够不受限制拜访源代码的存储库,然而这存在重大安全漏洞。因为开发人员并不需要拜访所有的内容,他们只须要拜访正在解决的代码区域,有时甚至都不须要编写权限。 尽管拜访受限会升高开发速度,但却能帮忙企业放弃代码的互不依赖性和模块化。如果开发人员只能对他们正在开发的模块进行更改,被迫和我的项目的其余局部放弃拆散,即便不思考安全性,这也是一件对企业无利的事。 无法访问整个源代码的员工,无论是出于歹意或无心,对企业造成的侵害是十分无限的,因而能进步企业零碎和代码的安全性。当然即使在受限拜访的策略之下,IT 部门也必须在开发人员来到企业后及时撤销起对源代码存储库的拜访权限。 4. 硬编码密钥(Hardcoded Secret)Secret 是提供应用程序到应用程序(application-to-application)拜访的在线凭据。它能够是 API 密钥、云凭据、加密密钥、数据库拜访详细信息等。欠缺教训的开发人员会在代码中应用纯文本密钥进行初始开发,这是一种常见的做法。然而随着开发的进行,这些 secret 会被遗记并留在那里,从而导致泄露危险。托管在 GitHub 等公共云服务上的源代码很容易被歹意攻击者利用。因而,开发人员在代码上传到云之前须要先扫描其中是否蕴含脱漏的 secret。 即便源代码从未公开,大多数编译后的代码也能够进行逆向工程。代码混同(Source code obfuscation)能够帮忙减少逆向工程编译代码的难度。不过,正确保存密钥才是避免泄露的最好形式哦! 5. 谬误提醒中裸露信息通过参考具体的谬误提醒来调试代码是开发人员的日常。但这些谬误提醒可能为歹意攻击者的提供参考信息。因而,谬误提醒须要对用户有所帮忙,但同时也要留神不能提供任何无关代码如何运行的任何信息!暗藏无关代码构造、数据结构和与其他软件连贯的信息。与此同时,请确保及时发现和解决异样。 总 结通过理解这些不良编码习惯以及如何养成更好的习惯,企业就可能开发更平安的代码。有了对不当的编码行为的认知,企业能够开始试着留神开发人员目前的开发习惯,并记录下来一些可能导致平安问题的行为,与开发团队一起探讨并寻找解决方案。如果开发团队的成员都有着良好的开发习惯,那么企业的代码平安将会回升到一个新的高度。

August 19, 2022 · 1 min · jiezi

关于coding:CODING-DevOps-高级架构师王炜入选木兰开源社区首批导师

软件技术突飞猛进,GitHub 曾经进化成为人类软件的基因库,碰到问题先去 GitHub 上寻找适合的解决方案曾经变成了工程师解决问题的常见办法。开源和去中心化的社会合作逐步成为社会倒退的趋势,凋谢的开源生态环境更有利于行业的倒退。目前,许多企业、机构、社区等都在致力于中国开源社区的构建。 “木兰开源社区”建设于 2019 年 8 月,是由中国电子技术标准化研究院牵头,国家重点研发打算重点专项“云计算和大数据开源社区生态系统”的外围成绩。 木兰开源社区旨在促成产学研用各方开源畛域的交换,推动国家科技翻新成绩开源,增强企业、科教研单位和行业用户之间的沟通,推动开源成绩转化落地,同时为各类开源我的项目提供中立托管,保障开源我的项目的继续倒退不受第三方影响,通过更加凋谢的形式来打造和欠缺开源社区生态。 木兰开源社区失去了科教界和产业界的极大关注,托管和孵化我的项目逐步增多,为更好的推动木兰开源社区我的项目的孵化毕业,启动了我的项目孵化导师团队和“导师招募打算”。 来自腾讯云 CODING 团队的王炜有幸成为第一批 9 位“开源我的项目导师”之一。 王炜是腾讯云 CODING DevOps 高级架构师,腾讯云首位 CNCF 大使,KubeCon 评审委员会成员,《Istio Handbook》 编委会成员兼作者,开源我的项目 Nocalhost 的研发负责人。专一于云原生、Docker、Kubernetes、DevOps 及微服务相干的畛域。 始终以来,CODING 都继续关注开发者生态建设,心愿可能和开发者们独特合作和成长。目前,由 CODING 团队自主研发的产品 - 云原生开发环境 Nocalhost 已将全副源码及文档开源至 GitHub;放弃厂商中立,恪守 Apache 协定,所有开发者、合作伙伴皆可共建生态,为云原生开发奉献一份力量。 CODING 从创立之初就在事必躬亲地反对开源生态体系的建设,目前曾经实现了许多我的项目的开源。CODING 将继续致力于开源和社区的构建,让凋谢的开源文化惠及更多开发者。 点击立刻开启高效云端研发工作流

August 17, 2021 · 1 min · jiezi

关于coding:夯实基础踏步云升-云原生-DevOps-入门必读

近年来,随着云计算的深刻倒退,云服务、虚拟机、微服务逐渐遍及,现在软件开发工作对从业者提出了更高的技能要求。因而,软件工程师们不仅要会写代码,懂业务规定,还须分明本人的代码是如何部署到云端或虚拟机上,以及如何借助微服务缩短公布周期,进步部署效率。然而,如何系统地学习这些远超软件工程教学大纲的常识。 云计算时代 DevOps 的入门指南 Len Bass 最新著述《Deployment and Operations for Software Engineers》中文版 ——《云原生 DevOps 指南》现已全面上架。 全书共分十二章,采纳模块化的编排形式,全面系统地解说了古代软件开发波及的部署与运维常识和流程,包含虚拟化、云、容器、平台平安、微服务、系统配置、布署流水线、劫难复原等,可能帮忙传统程序员疾速胜任古代软件开发工作。 全书各章都会解说理论知识并提供配套的实际练习,同时还设置了议题供课堂分组讨论,有助于软件工程师、计算机或者软件工程相干业余的学生读者以及相干畛域的爱好者更好地了解章节内容。 作者简介 Len Bass:澳大利亚国家信息通信技术研究院(NICTA)高级主任研究员,卡内基梅隆大学(CMU)软件工程研究所(SEI)高级工程师,从事软件研发工作 50 多年。著有《软件构架实际》,该书荣获美国权威的软件开发杂志第九届图书效率大奖,对软件工程畛域影响深远。 John Klein:卡内基梅隆大学(CMU)软件工程研究所(SEI)次要技术成员,次要从事可扩大零碎架构方面的钻研。 译者举荐 从事软件行业多年,时常感叹这个行业工程化的单薄。较之建筑工程、软件工程的可靠性是堪忧的;“工程”波及人、流程、工具。本书着重于工具和流程方面的介绍。咱们冀望它不仅能给一线开发者提供有用的常识和技能,也能让技术管理者系统性地扫视团队的研发流程是否还有改良的空间,如何利用云原生和 DevOps 技术进一步晋升研发效力和品质。 —— CODING 创始人兼 CEO 张海龙 点击链接即可动手《云原生 DevOps 指南》 舒适提醒:在 PC 端关上购买链接体验会更好

August 13, 2021 · 1 min · jiezi

关于coding:持续演进的云原生应用交付

本文作者:吴海黎 - CODING 研发总监 负责继续部署产品设计,帮忙多个行业客户实现研发效力的方案设计与最终落地。什么是云原生云原生是领导企业应用上云的方法论和技术体系,蕴含利用的开发、交付、运行时等阶段, Cloud Native 能够了解为: Cloud 示意利用运行在云端,而非传统的 IDC;Native 示意利用从设计之初即思考到云的环境,原生为云而设计,在云上以最佳姿态运行,充分利用云平台的弹性和麻利。对云原生的了解,各家厂商在不同工夫有不同的定义: 2013 年,Pivotal 公司的 Matt Stine 首次提出云原生“CloudNative”的概念;2015 年,Matt Stine 在《迁徙到云原生架构》一书中定义了合乎云原生架构的几个特色:12 因素、微服务、自麻利架构、基于 API 合作、扛脆弱性;2017 年,Pivotal 最新官网对云原生概括为 4 个要点:DevOps + 继续交付 + 微服务 + 容器;2018 年,CNCF 更新了云原生的定义,新增服务网格“Service Mesh”和申明式 API。能够简略的总结为: 云原生 = DevOps + 继续交付(Continuous Delivery)+ 微服务(Micro Services)+ 麻利基础设施(Agile Infrastructure)+ 12 因素(The Twelve-Factor App)+ 服务网格(Service Mesh)+ 申明式 API。 云原生利用交付现状 CNCF 公布的「Continuous Delivery, June 2020」次要论断如下: 开源工具难以满足企业级公布需要中大型企业的公布场景,开源工具较难匹配,个别的解决方案是抉择上图中 2-4 种,基于企业本身场景,深度定制满足需要。Helm 不仅仅是包管理工具尽管 Helm 本身的定位是解决 K8s 利用的安装包治理,但也被广泛应用公布场景,对于这点其实不难猜测,基础架构由单体迁徙至微服务,同时也将利用的交付切分为细粒度的服务交付,但企业面向最终用户的价值交付,需由残缺的利用承载,繁多微服务价值为 0,因而从交付的完整性思考,Helm 被广泛应用于公布场景并不奇怪。Jenkins 正逐渐被代替Jenkins 及其生态(Jenkins X、Jenkins Blue Ocean)仍然是继续交付中次要被驳回的工具,但企业也在逐渐应用新工具代替,如承载 GitOps 理念的 Flux。Jenkins 定位于继续集成,用来做公布的场景是略显有力的,针对 Jenkins 公布下文也做出了剖析。继续演进的云原生利用交付从 CNCF 的调研报告中得出的外围论断是企业需要未被满足,继续交付的方法论和工具建设仍然处于继续演进中,上面咱们回顾一下云原生利用继续演进的重要方法论及相干工具。 ...

July 27, 2021 · 1 min · jiezi

关于coding:CODING-携手-CoDesign让设计与开发更简单

一个互联网产品从设计、开发到上线,离不开产品经理、研发工程师、设计师之间的层层合作,但若团队成员在合作中应用不同的工具,往往会耗费额定的对接老本。 为了让团队成员能将更多的工夫投入到打磨产品上,CODING 与一站式设计合作平台 CoDesign 单干推出新性能——CODING 事项内的上传附件性能现已反对从内部引入 CoDesign 设计稿。 研发工程师无需下载 Sketch、XD 等设计工具,即可在 CODING 的事项中,在线预览设计稿,查看标注切图;设计师在 CoDesign 更新设计稿,CODING 事项中的 CoDesign 设计稿也会实时同步更新。 这个新性能可帮忙企业买通团队合作闭环,疾速实现从设计定稿到开发直至最终公布的全流程,实现轻松交付。 对于腾讯 CoDesignCoDesign 是一站式的设计合作平台,无团队成员和性能应用限度,为企业提供笼罩多种设计合作场景的外围能力。反对 Sketch、Figma、XD、PS 等设计工具,可在线解析 Sketch、Axure 源文件;反对多类设计的预览、分享、交付、贮存、治理及调用;反对主动生成标准文档,反对多人同时保护组件库,随时查看标准文档中的标注、代码信息,一键告诉团队成员增加、更新组件库。 针对企业外部不同角色,CoDesign 提供各类设计合作能力反对。产品经理能够通过逻辑连线精准表白页面关系和交互流程;设计师可通过 CoDesign 对历史设计稿进行备份与治理;工程师则能够通过 CoDesign 的主动标注切图性能疾速实现需求。 连接产品设计研发上下游,晋升团队设计效率,把控设计品质及兼顾利用团队资源的 CoDesign,用意为企业打造最好的设计合作解决方案。 这一点,与 CODING“让开发更简略”的理念不约而同。本次 CODING 和 CoDesign 单干,一方面是为了给企业和团队打造一体化的办公体验,另一方面也是表明咱们两个平台在不远的将来,还将会陆续买通更多的内部渠道,为咱们的用户带来云端沟通合作的全新体验。 CODING × CoDesign简略操作,轻松关联返回 CODING(https://coding.net/)注册/登录账号。 在 CODING 中创立事项时,能够在「附件」栏中抉择「其余形式 - CoDesign 设计稿」关联相干设计稿。 若是首次上传 CoDesign 设计稿,须要依据指引登录 CoDesign 账号。 登录实现后,抉择设计稿我的项目 -> 分组 -> 画板,勾选确认即可将设计稿与事项关联。事项内可关联多个设计稿。 留神:CoDesign 的设计稿更新后,CODING 附件中的设计稿内容也会实时同步更新。 ...

July 26, 2021 · 1 min · jiezi

关于coding:CODING-持续集成-自定义插件满足你多样化的构建需求

企业级的利用构建对构建速度、代码品质、构建性能、流水线易用性及易维护性都有较高的要求,企业研发团队通常须要集成第三方零碎工具或插件,一直晋升整个构建过程中的效率、品质和体验。基于不同的治理及构建场景需要,每个团队对于插件的能力要求各异。 近期,CODING 继续集成在为用户提供了 10 余种罕用的官网插件的根底上,推出了用户自定义插件能力,让团队内成员将得心应手的工具或命令封装成「自定义插件」,便于在构建流程中疾速配置所需的插件能力,并反对在团队内共享,不便团队内其余成员疾速复用。 自在定制 自定义插件不限度技术栈和语言框架,任意命令行可执行程序,均可封装成插件。开发团队可自行开发或应用开源插件来满足团队的构建需要,满足多样化诉求。上传即可应用,无需官网审核。 图形化编排 基于 CODING 继续集成的图形化编排能力,在插件的利用上,间接在构建的流程配置步骤中间接抉择插件即可,简略易用。 企业级插件治理能力 自定义插件反对企业/团队内共享,团队成员上传插件可抉择公开给企业内其余成员应用,有利于开发团队成员间的工具共享,进步开发者的创造力,节俭重复造轮子的工夫精力。 自定义插件怎么用? 1.查看构建插件 点击首页左侧的「性能设置」→「继续集成」→「构建插件」,你能够在此处看到官网插件、团队插件与集体提交但未公开的插件。在插件详情中查看名称、形容与版本号。 2.开发插件 插件开发不限度开发语言和环境,仅需满足插件的目录构造标准(如下)以及申明文件的标准要求即可。编写你的插件代码时,逻辑代码保留至 my-plugin-project/src 目录或任意子目录下,步骤运行入口文件确保与申明文件中统一。 插件目录构造: - my-plugin-project // 您的我的项目目录- my-script.xx // 构建插件执行脚本或入口文件,反对任意语言组织(需执行环境具备,如需非凡环境可应用容器)- qci-plugin.yml // 构建插件申明文件,定义您的构建插件名称、版本、参数等信息请点击查阅申明文件标准及更具体开发指引。3.上传插件 开发实现后,打包插件代码(zip 包)并通过「性能设置」→「继续集成」→「构建插件」中上传。咱们会保留您的我的项目文件,构建时,构建节点将会下载我的项目并执行。上传后确认公布插件,公布后可设置公开团队内成员可见。 4.应用插件 你能够通过图形化编排界面或编译命令行两种形式应用插件性能。当插件为公有插件时,只有作者自己能力增加应用,当作者将插件标记为「公开」后,团队内其余成员也将能够看到并应用此插件。 图形化编排形式点击指标「构建打算」→「设置」→「流程配置」,在阶段内增加步骤时抉择是否启用官网插件或团队的自定义插件。 编译命令行形式反对应用命令行的形式间接编辑 Jenkinsfile,参考语句示例如下: useCustomStepPlugin(key: 'exec_py_script', version: '1.0', params: [site_packages:'false',requirements:'false']) // key 为 插件的 ID,version 为版本号(默认应用最新版本,随插件降级而主动降级),params 为以后插件所须要填写的参数。本次提供的「自定义插件」扩充了 CODING 继续集成的构建能力边界,满足更多个性化的软件构建需要,给宽广研发团队提供了最大限度的灵活性,也进步了构建流程配置的效率和易用性。将来,CODING 继续集成也将逐步兼容 Drone 和 GitHub Action 的插件,一直构建 CODING 继续集成插件生态能力。

July 9, 2021 · 1 min · jiezi

关于coding:CODING-带你看腾讯新闻-7-日-DevOps-实践

随着越来越多的企业迈向了数字化转型过程,数字化技术也给作为撑持的云计算基础设施提出了更高的要求。同时,在疫情的影响下,不论是大型头部企业还是小型守业公司都在寻求管制经营老本和晋升效率的形式。当越来越多企业在历经数字化改革时,一个闪亮的名词——DevOps 呈现了。DevOps 是一组过程、办法与零碎的统称,基本在于突破不同部门之间的隔膜,让团队独特合作,在保障产品质量的前提下更快更频繁地交付更加稳固的软件版本。目前,业界许多知名企业曾经走上了 DevOps 之路,在上面这个视频中,咱们将会把镜头拉近腾讯新闻,体验他们研发团队的 DevOps 最佳实际之旅。 视频 CODING 带你看腾讯新闻 7 日 DevOps 实际 在疫情和业务疾速扩大的影响下,诸多企业渴望老本管制和效率晋升。DevOps 模式曾经成为了古代 IT 乃至传统企业合作与共享文化的体现和利用。一体化的 DevOps 平台正在成为 DevOps 发展趋势,比方国内的 CODING DevOps。如果想要突破团队沟通的壁垒,进步企业研发效力,那么实际 DevOps 不失为一种卓有成效的办法。 附录 腾讯新闻挪动端 7 日 DevOps 实际 CODING DevOps 产品能力总览 点击体验 DevOps 最佳实际之旅

July 8, 2021 · 1 min · jiezi

关于coding:CODING-助力推进腾讯游戏国际化进程

海内市场体现亮眼,挑战重重迎难而上 通过多年的积淀,国内游戏市场已逐渐迈入平缓的倒退阶段。为寻求新的倒退空间,不少游戏厂商凭借在国内打磨的竞争力,开始将眼光锁定海内市场,布局游戏出海新赛道。近两年,腾讯作为国内头部的游戏厂商,除了坚固国内占据的领导位置之外,海内业务同样倒退迅猛,海内市场获得了不容忽视的优异成绩。 为应答复杂多变的海内市场,撑持游戏业务的全球化倒退,IEG 成立了专门的国际化部门 IEG Global 来对立治理游戏出海,解决国际化停顿中遇到的问题。因为以后 IEG Global 反对的工作室遍布寰球,大家在游戏的开发、集成和部署等环节遇到了一些自动化、标准化的问题,再加上语言、文化、习惯等差别,为腾讯游戏出海也带来多重挑战。 CODING DevOps 助力腾讯游戏征战海内市场 在这样的大背景下,IEG Global 亟需一套贴合开源生态、具备国际化认知的 DevOps 平台,为腾讯游戏国内和海内 Studio 的开发流程对接和经营流程提供高效反对,从而实现各个团队的敌对合作与文化交融,减速整体业务的交付过程。 腾讯云 CODING 是腾讯云旗下一站式 DevOps 开发合作平台,涵盖了代码托管、项目管理、测试治理、继续集成、制品库等多款产品和服务,满足了软件开发从构想到交付的要害所需,实现研发团队在云端的高效协同,实际麻利开发与 DevOps,全面晋升软件交付的品质与速度。 CODING 为 IEG Global 搭建了一整套国际化的 DevOps 平台,具备代码治理、继续集成、制品治理等能力。通过对国际化团队的对立治理,可无效解决因地区差别、能力差异导致的代码品质问题,升高软件开发过程中的沟通老本,晋升研发效力。因为游戏业务的特殊性,CODING 为 IEG Global 构建了制品的寰球同步能力。通过该能力,可保障制品的跨区域交付,晋升部署的效率和品质。寰球各大工作室开发的游戏,可高速、高效地部署至寰球各个区域,充沛满足游戏业务的国际化需要。另外,此次为 IEG Global 打造的 DevOps 平台着眼全球化场景,在平台语言上也可能反对中英文切换,从而满足不同国家的开发人员应用需要。 通过与 IEG Global 单干的深刻,CODING 将为开发者提供更弱小的自主开发能力,充分利用云资源,以凋谢及容纳的姿势接轨世界生态 ,打造全球化的品牌形象,全面推动 IEG Global 的国际化过程,助力腾讯游戏征战海内。

July 6, 2021 · 1 min · jiezi

关于coding:仰望天空脚踏实地-CODING-OKR-全新上线

工作中你是否也为此困扰要害绩效与指标脱节,在执行中员工只埋头于本人的要害绩效,而疏忽了指标自身,造成员工眼光止于眼前,工作浮于外表。 指标的执行和实现状况总是模糊不清,争议一直,跨团队合作十分艰难,部门墙林立。 指标执行进度难以追踪和把控,一旦业务繁冗,团队就开始慌手慌脚,难以聚焦重点、提前辨认危险、及时调整。 OKR 的价值之美为解决管理工作上的矛盾,适应进一步欠缺的公司管理制度和全新理念,由 Intel 创建的指标管理工具 OKR(Objective and Key Results,指标与要害后果法)逐渐浸透进国内,通过后果去掂量过程,促成员工与团队踊跃协同工作,帮忙组织实现目标治理、推动执行与合作。 与过来十几年占据支流位置的 KPI 相比,OKR 具备更显著的先进性。宏观上,KPI 是该框架内的度量值,OKR 是一个策略交付框架,KPI 是“要我做的事”,OKR 是“我要做的事”;实质上,KPI 是多个组织绩效考核的根底和根据,OKR 则是员工被动对团队总体目标思考的前提下,自我确立指标、自我打算、自我管理的能动性工具。 CODING OKR 助力企业点亮新价值为满足企业一直晋升的治理诉求,CODING 深刻调研了国内企业在指标治理上的痛点,通过层层打磨,现推出全新的 OKR 性能。新版 CODING OKR 将更好地帮忙企业聚焦组织指标,优化协同体验,激发团队内驱力,推动企业治理指标的全面落地。 周期灵便设置OKR 启动阶段第一步就是构建 OKR 专项落地团队和确定 OKR 的施行流程,并根据团队的业务类型和节奏设置周期,通过 CODING OKR 能够灵便地进行指标周期的设置与治理,正当的周期会让指标更具挑战,更能适应企业以及市场环境的变动。 指标精准聚焦OKR 的制订是以业务增长为指标,以公司策略为方向,是管理层和员工独特布局的后果,是自上而下与自下而上的联合。 在 CODING OKR 的撰写阶段,管理层对齐指标之后,会根据公司的总体目标来设定层级清晰的团队指标,创立相应的 KR 并指派责任人和成员,根据每条 KR 的重要性和优先级进行权重的设定。 从输入到实现,CODING OKR 可对其实现全流程追踪,工作的实现水平变得数据化、立体化。员工可依据工作的权重、优先级进行工作安顿,管理者则对员工的工作实现状况高深莫测,轻松把握指标进度。 工作公开通明秉承 OKR 公开通明的理念,在 CODING OKR 上,无论员工、管理层、CEO 都可查看公司任何一位成员的 OKR。纵向上,员工能向上对齐,联合下级的 OKR,思考并制订本人的集体指标;横向上,员工能通晓部门、跨部门共事的工作工作,缩小重复劳动,彼此促成,互相支持,从而晋升合作与沟通效率。 多层指标关联CODING OKR 的集体指标不仅能够由成员根据团队指标本人撰写,还能由部门负责人依据某条团队的 KR 进行指派,从而实现团队 KR 与集体指标紧密结合。 ...

May 8, 2021 · 1 min · jiezi

关于coding:2021-DevOpsDays-东京站完美收官-CODING-专家受邀分享最新技术资讯

DevOpsDays 是一个寰球出名的系列技术会议品牌,内容涵盖了软件开发、自动化、测试、平安、组织文化以及 IT 经营的社区会议等。DevOpsDays 由 DevOps 之父 Patrick Debois 学生开办,组织中汇聚了互联网、金融以及各行各业的 DevOps 实践者,通过分享、交换彼此先进的技术思维、理念和业内最佳实际,各界精英和行业内顶尖专家以口头推动了 DevOps 在寰球范畴的落地。在过来十年的倒退中,DevOpsDays 以城市为单位迅速席卷寰球,当之无愧地成为了 DevOps 圈中最具影响力的国内盛会。 在 2021 届 DevOpsDays Tokyo 大会上,泛滥 DevOps 畛域大咖们带来了精彩的主题分享。DevOps 之父 Patrick Debois 也在线上为参会者答疑,分享最具价值的 DevOps 实际。CODING 资深技术专家、布道师——周纪海也受邀参加大会并在线上以 DevSecOps 工具与实际为议题进行分享。 以下为周纪海在 DevOpsDays Tokyo 上分享的演讲内容——《 DevSecOps 在大型银行中的落地实际》 DevSecOps 概念、诞生原因及劣势简介 DevSecOps 是 Gartner 在 2012 年就提出的概念,其原始术语是" DevOpsSec "。2017 年 RSA 峰会之后,DevSecOps 开始成为世界热门话题。DevSecOps 基于和连续 DevOps 的理念,其设计与执行依然处于 Agile 的框架之下。DevSecOps 的指标是将平安嵌入到 DevOps 的各个流程中去(需要,架构,开发,测试等),从而实现平安的左移,让所有人为平安负责,将安全性从被动转变为被动,最终让团队能够更快,更平安地开发出品质更好的产品。 传统模式下,在整个研发流程(需要,开发和测试)实现之后,在上线前须要进行平安评审。因而整个交付周期就是研发时长加上平安评估的时长。DevOps 模式下,通过自动化,麻利开发,团队合作。微服务设计等 DevOps 理念将整个研发阶段的时长缩短了,从而缩小了交付周期。然而,因为传统的 DevOps 模式没有思考平安,因而上线前的平安评审时长并没有因而扭转。这里能够清晰的看出,整个研发流程的瓶颈是在上线前的平安评审阶段。DevSecOps 模式下,因为无感地左移了上线前平安评审的局部工作到开发团队,使得平安评估阶段的时长变短,从而进一步缩短了交付周期。DevSecOps 能够给研发效力提供诸多益处,次要体现在三个方面: ...

April 23, 2021 · 1 min · jiezi

关于coding:开发环境上云打造五星级开发体验

本文作者:王振威 - CODING 研发总监全文约 5000+ 字,预计浏览工夫 20 分钟云是从传统 IDC 机房演进而来,一开始云的定位只是为了解决数据中心的弹性计算,高可用等问题。能够说,私有云让成千上万家企业灵便地按需租用数据中心资源成为可能,同时在推动社会数字化倒退上起到了关键作用。 但简简单单的把云了解为资源的按需租用太狭窄了,随着云技术和行业标准的倒退,云原生的概念开始呈现。云原生改革了传统利用,传统的利用能够运行在本地开发电脑上,到真正正式提供生产服务才被云以弹性的,高可用的资源提供形式接管。而云原生利用跟传统利用不一样,传统利用面向操作系统编程,云原生利用间接面向云编程。云原生利用很难在非云的环境里开发,调试,测试和投产。 CODING 致力于服务开发者,在云倒退的时代也始终在积极探索用云的技术和理念来解决理论问题。随着公司业务倒退,技术革新,CODING 本身也始终在践行最先进的开发方式,拥抱上云过程。CODING 的开发环境演进大抵经验六个阶段,逐渐打造了五星级的开发体验。 六个阶段的倒退过程,其实也是开发环境逐步上云的过程,从 0% 到 100% 的开发环境上云,在第六个阶段,CODING 应用 Nocalhost 实现了 100% 的开发环境上云。随着上云过程的停顿,下图能够看到不同开发环境的体验星级。 下文将对六个阶段进行一一解说。 第一阶段:高配笔记本电脑CODING 2014 年创建,创建之初只有几个程序员,咱们跟大多数初创企业没有区别,一条家庭宽带 + 一个千兆无线路由 + 若干台笔记本电脑就能够着手开发第一个版本的 CODING 。 典型的状况是人手一台 MacBook Pro(i7 + 8G + 256G SSD),应用 JetBrains 系列 IDE 开发,写完代码在 IDE 里点运行或者调试,IDE 会主动编译并启动利用,开发者能够很不便地调试程序。事实上这个阶段的体验就是五星级的,但随着业务,技术等的倒退,开发体验逐步降落,苦不堪言。 此阶段根本情况过后 CODING 开发环境状况 开发者人数:10 人左右利用架构:Java 单体后端 + Angular.js 前后端拆散IDE:IDEA + WebStorm 开发构建形式:手动部署形式:云主机 + Nginx + Tomcat 部署开发环境:笔记本电脑 + TomcatCODING 服务启动工夫:10 秒同期云计算和技术架构行业倒退情况 ...

March 29, 2021 · 2 min · jiezi

关于nocalhost:专访-CNCF-大使王炜让云原生开发回归原始而又简单

近期,腾讯云 CODING DevOps 开源了云原生开发环境 - Nocalhost。 依据官网文档介绍,Nocalhost 来源于 No Localhost,其含意是开发者不再依赖本地计算机的编码、调试和测试过程。他是一个云原生开发环境,旨在解决云原生下开发难的问题。 例如,在 Kubernetes 环境下进行微服务开发,通常会面临以下问题: 每次批改代码,都须要通过构建映像->推送映像->拉取映像->重新启动应用程序(Pod)的过程,开发的反馈循环十分长(10 分钟以上);为了开发某个微服务,必须要在本地启动整个环境和所有微服务,这带来了适度依赖本地资源的问题;开发人员只专一于他们本人的服务,随着迭代的进行,本地启动或更新残缺的开发环境越来越难;微服务之间的依赖关系和启动程序难以管制;新入职的员工个别须要 2-3 周的工夫来相熟开发环境的搭建及学习背景常识 那么,Nocalhost 到底是怎么解决以上问题的?Nocalhost 的开源,又会给 K8s 生态带来哪些影响呢?带着这些问题,咱们与 Nocalhost 的设计者之一、新晋 CNCF 大使、云原生社区成员,来自腾讯云 CODING DevOps 的王炜,具体聊聊对于 Nocalhost 的产品、技术和生态。 采访嘉宾 以下为采访原文:Q: 首先跟大家介绍一下 Nocalhost 的起源吧王炜:Nocalhost 的起源其实是解决 CODING 本身开发难的问题。CODING 在晚期曾经拥抱微服务、云原生和 Kubernetes,但在咱们日常开发过程中,发现 Kubernetes 尽管解决了部署和运维的问题,但同时也带来了开发难的问题。 最典型的痛处是每写几行代码,要察看代码成果或者调试,就不得不从新构建镜像->推送镜像->批改工作负载镜像版本->期待 Pod 重建的漫长过程。这个过程尽管能够用自动化的 CI/CD 来解决一部分人工手动运行问题,但其外围不变。 此外,本地全量运行 CODING 所需的资源要求十分高,晚期开发人员不得不装备一台 8 核 64G 的电脑来开发,后续也尝试过为每个人都装备了一台近程的高配开发机,但开发效率依然无奈晋升。 针对这种场景,咱们开始摸索相应的解决方案,并最终将该实际开源成为了 Nocalhost 我的项目。 Q:在云原生环境下,开发难除了体现在每次编码须要从新构建镜像以外,在实践中还遇到了其余痛点吗?王炜:痛点十分多!当前端同学为例,从入职开始,相熟和配置开发环境须要花大量的工夫和精力。另外,好不容易搭建好了开发环境,须要更新微服务组件时往往呈现大量组件无奈启动。当然这可能更多的是利用治理问题了,目前社区也有十分好的利用模型实际。 但问题是,对立保护这套利用模型是十分吃力的,如果应用它的场景十分低频,那么问题裸露会越来越迟,最终与无人保护没有多大差异。而所有开发者的环境又是独立的,遇到问题总是本人解决而不是往下层去更新利用模型,这会进一步导致利用版本越来越老旧。 所以,咱们思考开发环境是必须要集中化治理,开发环境的部署起源只能是独立保护的利用模型,业务组协同保护并产生部署-批改循环效应,能力实现一致性的利用治理。 Q:所以 Nocalhost 会治理利用和开发环境吗?王炜:是的。利用治理是应用内部规范,例如 Manifest 文件组合成的利用、Helm 利用和 Kustomize 利用等,它是用于拉起开发环境的规范装置办法,不同的开发者的开发环境在 Nocalhost 里的定义是开发空间(DevSpace),目前是采纳 Namespace 的形式进行隔离和治理的,不同开发空间后续将反对合作开发。利用和开发空间的治理都能够在 Nocalhost 控制台来实现。 ...

March 25, 2021 · 2 min · jiezi

关于coding:专访仙工智能叶杨笙工业产品如何提升研发效能

本文约 4000+ 字,预计浏览耗时 12 分钟。采访背景2012 年美国提出工业互联网策略,2013 年德国提出了第四轮工业革命“工业 4.0”,2015 年我国推出“中国制作 2025 ”。毫无疑问,一个全面自动化、数字化、智能化的工业时代正在减速到来。这个信息化与工业化深度整合的过程,是工业互联网、云计算、大数据在企业研发设计、生产制作、经营治理、销售服务等全流程和全产业链的综合集成利用。软件研发治理平台作为工业软件研发的引擎,如何帮忙制作企业实现高效产品研发与麻利生产? 本次采访的仙工智能是一家专一于智能生产和智慧物流的高新技术企业,业务涵盖了通用 AMR(Autonomous Mobile Robot)控制器、仙工智能企业数字化中台 SEED、基于视觉技术的全感知 AI 零碎 RoboView 及主动叉车等 AMR 产品。仙工智能于 2020 年实现了销售额破亿,且业务增速达到一倍以上。仙工智能联结创始人兼产品总监叶杨笙,在移动机器人控制器畛域有多年的产品研发以及企业治理教训,致力于推动 AMR 控制器产品疾速迭代并获得了行业领先地位。 本文将带大家从研发工具、研发流程、研发团队建设等多个角度来理解仙工智能对于工业产品研发效力晋升的摸索,心愿对工业以及其余行业的研发团队有所裨益。 01CODING: 首先想请叶总介绍下仙工智能目前的外围业务以及策略倒退方向。 叶杨笙: 咱们目前总共有四大块业务。首先最外围、做的最久以及占比最大的业务就是机器人外围控制器,次要是用于智能制作、工厂生产物流的场景。 第二条业务线是从外围控制器延长进去的机器人本体业务,分为主动叉车、小型工业 AMR。咱们重点会放在主动叉车,因为小型 AMR 曾经很成熟了,咱们不会投入太多去制作机器人本体,而是更加专一做外围管制模块,给业内生产机器人本体的企业提供外围控制器。因为主动叉车是个新畛域,所以咱们会先研发整机,在成熟之后咱们也还是会专一做叉车的外围控制器。 第三条业务线是咱们的第二代系统软件产品体系——仙工智能企业数字化中台 SEED,这个数据中台包含了四大模块:移动机器人业务施行工具(KHS)、机器人及自动化设施资源调度零碎(RDS)、仓储物流管理系统(WMS)、设施运行时数据可视化显示零碎(V)。 第四个业务,就是基于视觉技术的全感知 AI 零碎 RoboView,利用人工智能、机器学习等 AI 算法来进行移动机器人的视觉导航、视觉辅助定位等,实现车厂协同,这块业务在整个行业都处在比拟新的阶段,尽管对外还未正式销售,然而曾经在很多我的项目中进行产品验证了。 02CODING: 也就是说仙工智能的业务中既有硬件产品也有软件产品。在工业产品研发过程中,以您的教训,硬件研发和软件研发相比哪个难度更高? 叶杨笙: 我感觉难度差不多,但区别还是很大的。比方两者迭代速度不同,软件比拟麻利,根本每周能够出一个版本。硬件的迭代周期就长很多,比方开发一块电路板,从原理图、 PCB 、再到打板,一般来说一个月能迭代一个版本,达到一个稳固的版本至多须要五到六个版本的工夫,那么大半年就过来了。随着研发能力的积攒,目前咱们降级硬件版本的速度曾经比以前快很多了,根本每个月都能迭代一到两个版本。 03CODING: 能够看出你们在进步产品研发效率方面费了不少功夫。在之前的产品研发过程中,仙工智能遇到了什么问题,促使你们去寻找一个相似 CODING 的研发工具? 叶杨笙: 那故事得从守业之初开始说了,刚从学校毕业开始守业的时候,咱们还是用着 SVN 的代码合作形式,这种形式根本能够满足几个人的合作。随着团队人数开始扩张,咱们开始尝试自建 GitLab 来应用 Git 合作,但发现自己保护服务器十分麻烦。 起初就搬到云端,开始应用 GitHub,随着人员规模进一步壮大,咱们团队发现没有业余的需要/缺点反馈渠道,咱们就应用了一个开源的工具 Redmine 来做缺点治理跟踪。这套工具继续一段时间之后,咱们团队察觉这种形式还是不够高效:比方代码和需要的治理是割裂的,开发人员心愿的是代码的提交能够关联到某个缺点或者需要;而且 GitHub 没有一个我的项目的概念,就会导致咱们的我的项目代码分布在几十个仓库中,这种形式并不实用较大规模的企业研发团队应用。 于是咱们就开始找新工具,在找到 CODING 后,发现 CODING 和企业微信的联合也十分顺畅(因为咱们公司在应用企业微信),研发治理的功能完善度也十分高,咱们就决定了应用 CODING。 ...

March 25, 2021 · 1 min · jiezi

关于coding:腾讯全资子公司-CODING-2021-届春季校招补录全面启动

March 9, 2021 · 0 min · jiezi

关于coding:CODING-联合-TKE让应用发布更便捷

随着互联网服务的竞争进入红海,IT 服务的复杂性加大,用户对于软件工程的速度与品质有了更高的谋求。在这样的大背景下,DevOps、容器、微服务逐渐取代传统的开发模式成为云原生的要害组成部分,腾讯云更是凭借齐备的产品矩阵、零碎的布局和宽泛的实际成为云原生畛域的领跑者。 通过腾讯云生态体系的构建,其外围云产品 CODING CD 和腾讯云容器服务 TKE 也实现了技术的交融和产品状态上的买通。近期 CODING CD 将在原 TKE 集群的根底上,进一步减少 EKS 弹性集群的入口,一方面为开发者提供了更为灵便的部署流程编排,另一方面新入口的退出将减速两侧产品的用户交融,促成腾讯云云原生生态的拓展与欠缺。 ▲ CODING CD 和腾讯云 TKE 买通后的产品界面 在万物上云的明天,频繁变更和产品服务稳固变成了天平的两端,规范化的软件公布流程、灰度公布策略能够帮忙企业更好的均衡两者。CODING CD 作为上下游买通的强整合工具零碎,无缝对接 Kubernetes 场景及腾讯云弹性伸缩(Auto Scaling),并基于 Spinnaker 能力,在云原生技术栈中实现疾速交付,减速并简化云原生利用的部署,可继续、可控、自动化地把软件制品公布到服务集群中,反对蓝绿公布、灰度公布(金丝雀公布)等多种部署策略。 ▲ 无缝对接 Kubernetes 场景 ▲ 反对多种部署管道 腾讯云容器服务 TKE 是基于原生 Kubernetes 提供以容器为外围的、高度可扩大的高性能容器治理服务。在该产品根底上,腾讯云容器团队拓展出弹性容器服务 EKS 产品状态,为客户提供毋庸购买节点即可部署工作负载的服务模式。EKS 兼容原生 Kubernetes,反对应用原生形式购买、治理资源,并扩大反对腾讯云的存储、网络等产品,开箱即用。除了行将减少的 EKS 弹性集群入口外,将来,CODING CD 还将持续引入腾讯云服务网格 TCM,基于服务网格 TCM 对业务开发通明、通用无侵入的服务连贯治理与多层级全链路观测能力,通过单方产品能力的买通,让公布流程自动化、可管控,从而升高企业公布危险。 后疫情时代,企业上云不只是单纯地将本地机搬上云上虚拟机,而是抉择更加实用于云的架构、开发方式和资源利用形式,以赋能业务倒退。在云原生的实际之路上,CODING 将携手腾讯云 TKE,面向云原生 DevOps,联合单方团队劣势与技术能力,减速企业 IT 改革。CODING 也会进一步拥抱腾讯生态,加深与腾讯云内云原生系列产品的单干,继续助力云原生的技术精进,全面开释云原生新价值。

February 2, 2021 · 1 min · jiezi

关于coding:CODING-再携手腾讯云-Serverless让开发者跑步上云

近年来,腾讯云继续在云原生畛域打磨和欠缺产品矩阵,致力于为开发者上云提供更好的产品和服务。继前段时间 CODING CI 助力腾讯云 Serverless 全新利用控制台、继续保障 Serverless 利用疾速部署稳定性之后,CODING DevOps 和腾讯云 Serverless 产品进一步单干,在多场景上为开发者提供了更加便捷的应用形式,让开发者跑步上云。 DevOps 与 Serverless 均是云原生的重要一环。如在前不久 Techo 开发者大会上公布的《腾讯云原生路线图》 中云原生最佳实际环节所介绍的,CODING DevOps 及腾讯云 Serverless 均在云原生畛域提供了优良的产品服务,取得了开发者的高度认可。CODING DevOps 作为一站式 DevOps 平台,提供项目管理、代码托管、继续集成/部署、测试治理等性能,帮忙用户疾速开启高效的云上研发工作流,实现研发效力降级。而腾讯云 Serverless 为开发者提供的高效易用、平安稳固的无服务器计算平台,具备弹性伸缩、一键部署、罢黜运维等个性,开发者无需关注撑持应用服务运行的底层资源,只需开发最外围的业务逻辑即可。 Serverless 和 DevOps 的联合,意味着用户能够在弱小的云计算能力帮忙下享受弹性伸缩、秒级部署的服务,同时可能解决公布流程低效、IT 建设保护老本昂扬等造成研发效率低下的问题。 目前,CODING DevOps 和腾讯云 Serverless 产品曾经进行了多方产品性能的买通,例如: 基于 CODING 团队自主研发的在线集成开发环境 Cloud Studio,腾讯云 Serverless 推出了云函数在线开发 IDE——Serverless Web IDE,为用户提供靠近本地 IDE 的云端开发体验。开发者可在浏览器内实现函数创立、编写、在线测试、部署全流程操作,省略代码本地推拉的繁琐步骤,真正享受“拎包入住”。Serverless 利用创立反对导入 CODING 代码仓库,间接从开发者的现有 CODING 仓库拉取代码进行部署。每次更新仓库代码时,Serverless 都会主动为其部署,进步开发效率。CODING 基于腾讯云 Serverless 能力,降级动态网站托管服务,解决了旧版访问速度不稳固、DDoS 攻打穿插影响等问题,提供了高效残缺的部署流程。CDN 减速、SSL 证书治理、全流程构建、异样告警等新个性也使开发者的应用体验更加顺畅。在疫情和业务疾速扩大的影响下,诸多企业渴望管制老本的同时晋升效率,云原生技术在其中施展了重要的作用。CODING DevOps 携手腾讯云 Serverless 在多层面进行深度联合,轻量化、灵便、高扩展性的工具和服务升高了资源老本与配置管理的复杂性,使得用户将繁冗冗余的开发配置工作抛之脑后,领有更残缺和晦涩的开发部署体验。将来,CODING 和 Serverless 还将扩大深度能力,如动态网站监控、动静网站等。作为继续在云原生畛域深耕多年的产品团队,CODING 和 Serverless 将联合各自劣势通力合作,共建和丰盛腾讯云原生生态,为国内开发者的云原生路线增光添彩。 ...

January 29, 2021 · 1 min · jiezi

关于coding:CODING-现已支持墨刀原型引入

一款产品从设计、开发到上线,最后的灵感可能会在不同工具间流转,团队内会产生大量额定的操作、沟通和耗费。 为了突破这些壁垒,让工作流程更畅通,团队能专一于打磨产品, CODING 与在线产品原型设计与合作平台 墨刀 单干推出实用小性能 —— CODING 事项内的上传附件性能现已反对 从内部引入墨刀原型。 在事项当前页间接查看设计原型图,团队外部可能更加快捷高效地对设计原型进行探讨、批改、更新,带来更加顺滑的工作体验。 CODING 标准版现已 完全免费 ,不限人数应用!操作指南简略3步实现墨刀原型引入1、登录 墨刀 ,抉择须要导入进事项的墨刀原型,点击【分享】按钮,抉择【嵌入第三方】并复制代码。 2、返回 CODING 事项治理,进入任意史诗、需要、工作或缺点中,在增加附件中抉择【内部引入】-【墨刀原型】。 3、通过粘贴墨刀的嵌入代码,将原型与事项关联,就能在 CODING 中间接查看设计原型了! CODING 标准版现已完全免费,点击理解更多

August 10, 2020 · 1 min · jiezi

各种各样的镜像加速

各种各样的镜像加速mirrors-for-coder这里做一个集中,尽管以前都是遇到时立即搜索,但是集中一下之后,看起来也很壮观的。 当然,欢迎完善它。 https://github.com/hedzr/mirr...China MirrorsGitHub Clone通过HTTPS协议Clone仓库的话,可能会遇到速度很慢的情况。 根据经验,在慢的时候中断Clone捎带片刻重复命令的话,你可能会得到正常速度,这种偷鸡的策略适合于小小仓库。 对于大型仓库,改走SSH协议进行clone的话,走到正常速度的几率较大,但此时的速度相较于HTTPS而言通常会有所损耗。 但下面还有一种较为费事的方法,通过修改 hosts 文件来完成提速,无需科学也无需代理加速也无需镜像加速(GitHub是不太可能有镜像的)。具体来说请接下去阅读: 首先在 https://www.ipaddress.com/ 查询这三个域名的地址: github.comassets-cdn.github.comgithub.global.ssl.fastly.net然后按照查询的结果填写到 /etc/hosts 中,windows用户请查找 %WINDIR%/system32/drivers/etc/hosts 文件。请注意修改 hosts 文件通常需要 sudo 权限 或者管理员权限。修改内容如同下面: 140.82.118.3 github.com185.199.109.153 assets-cdn.github.com185.199.111.153 assets-cdn.github.com185.199.108.153 assets-cdn.github.com185.199.110.153 assets-cdn.github.com151.101.113.194 github.global.ssl.fastly.net如果你有国外的服务器,也可以通过dig指令来查找: $ dig github.com +short140.82.118.3Docker CEDocker CE 的具体加速办法有很多种,然而各种版本的本质都是一样的,一般来说你需要找到 docker daemon 的配置文件 /etc/docker/daemon.json,然后修改它像这样: { "insecure-registries" : [ "registry.mirrors.aliyuncs.com" ], "debug" : true, "experimental" : false, "registry-mirrors" : [ "https://docker.mirrors.ustc.edu.cn", "https://dockerhub.azk8s.cn", "https://reg-mirror.qiniu.com", "https://registry.docker-cn.com" ]}如果你在这个文件中自定义了其他项目,或者这个文件中已经存在其他定义,请注意保持。 参考:https://docs.docker.com/engin... Ubuntu Apt Source如果你使用桌面版本,则 Ubuntu 的软件源设置中,你可以选取最近的地区,例如中国大陆,从而加速软件包下载速度。 ...

October 15, 2019 · 4 min · jiezi

把时间留给重要的事——Markdown 模板功能上线

你是否遇到过因为同事在任务中过于放飞自我而感到头疼?或者经历过因为内容描写的不系统而导致关键信息被忽视?现在,CODING Markdown 模板功能将帮助你解决这些困扰。功能介绍CODING 研发管理系统任务内容支持 Markdown 语言。Markdown 是一种轻量级标记语言,让写作者专注于写作而不用关注样式。CODING Markdown 模板功能主要用于解决企业在项目协作中的内容输出规范问题,同时可以在 CODING 研发管理系统各处的 Markdown 编辑框内实现快速填写指定内容的效果。选择模板后就可以直接根据模板填写内容功能设置企业所有者/管理员可以创建企业级别 Markdown 模板,企业成员通用。项目管理员可以创建项目级别 Markdown 模板,项目成员通用。个人可以创建个人的 Markdown 模板,仅自己可用。选择场景默认模板后,该场景下的 Markdown 编辑框将会自动填充模板内容,且场景默认模板的显示优先级为项目 > 企业 > 个人。功能演示项目 Markdown 模板项目 Markdown 模板功能仅项目管理员可见。项目管理员创建 Markdown 模板后,此项目内成员在本项目内的 Markdown 编辑框可选用。1、【项目】 -> 【项目设置】 -> 【模板设置】 -> 【新建模板】。2、填写模板名称、模板内容后,点击【保存】按钮即创建成功。3、建好模板后可在【模板设置】进行编辑和删除。4、在项目内的某处 Markdown 编辑框点击【模板】按钮(此处以任务编辑框为例)。5、在【选择 Markdown 模板】页面选择所需模板,点击【确定】按钮即可在编辑框内使用模板内容。企业 Markdown 模板企业 Markdown 模板功能仅企业管理员和企业所有者可见。企业管理员或企业所有者创建 Markdown 模板后,该企业下的所有企业成员在企业内所有项目的 Markdown 编辑框均可选用。【头像下拉框】->【企业管理】-> 【模板管理】。个人 Markdown 模板个人 Markdown 模板功能所有用户可用。用户创建 Markdown 模板后,CODING 研发管理系统所有项目内的 Markdown 编辑框均可选用。个人创建的模板仅自己可见。【头像下拉框】-> 【个人设置】->【模板设置】。场景默认模板现支持:项目描述、项目公告、版本发布和 Wiki 四个场景。【新建模板】->【编辑 Markdown 模板】->【选择对应默认模板】-> 【生产相对应的模板】设定规则:如把某模板设置为某场景下的默认模板后,则该场景下的 Markdown 编辑框将会自动填充模板内容。每个场景只能匹配一个默认场景模板, 同一场景选择新模板后旧模板会被替换。场景默认模板的显示优先级为:项目 > 企业 > 个人。比如企业、项目、个人均设置了针对任务描述的场景默认模板,此时在项目内新建一个任务,则默认填充项目级别的任务描述 Markdown 模板。点击链接,立即感受 Markdown 顺滑新体验! ...

March 26, 2019 · 1 min · jiezi

持续集成之理论篇

本文作者:CODING 用户 - 何健持续集成 ?——?大概数周前,突然有学长问我有没有接触过“持续集成”。在我脑海中,这是一个陌生的词汇,于是百度了解了一番。实际上有开发和部署经验的小伙伴对持续集成不会非常陌生的,特别是那些喜欢自己写 webhook 的小伙伴。这篇文章来聊聊持续集成。互联网软件从开发到上线,后续迭代更新,已经有一套近乎标准的流程。其中 持续集成(Continuous integration,简称 CI)则是核心流程。像「CODING 持续集成」也直接支持自定义配置流程。概念大师 Martin Fowler 对持续集成是这样定义的:持续集成是一种软件开发实践,即团队开发成员经常集成他们的工作,通常每个成员每天至少集成一次,也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建(包括编译,发布,自动化测试)来验证,从而尽快地发现集成错误。许多团队发现这个过程可以大大减少集成的问题,让团队能够更快的开发内聚的软件。简单说,持续集成就是指频繁自动将代码集成到主干和生产环境,比如「CODING 持续集成」所实现的功能。目的持续集成的目的,快速迭代,保持高质量,避免不必要的成本投入。优点快速定位错误,测试环节可以及时暴露问题;避免大幅度偏离主干,借助统一的代码库;减少不必要的成本投入,可以自动化解决的重复乏味的事情,没必要浪费人力和时间;实际上还有很多有点,大家慢慢感受啦~一般步骤持续集成的核心措施, 集成到主干前, 自动化测试, 只有通过,才可以集成到主干。成功集成到主干后,也意味着可以部署上线。这便牵扯出另外两个相关概念,持续交付、持续部署。这里一起看一下集成的一般步骤:设计开发测试发布每次集成都是这样的步骤,因此持续集成会时这些基本步骤合体的循环,只要项目还在迭代,我们就会不停重复这个步骤。持续交付 (Continuous delivery)这里借用阮一峰老师的说法:持续交付(Continuous delivery)指的是,频繁地将软件的新版本,交付给质量团队或者用户,以供评审。如果评审通过,代码就进入生产阶段。持续交付可以看作持续集成的下一步。它强调的是,不管怎么更新,软件是随时随地可以交付的。注意,持续交付在自动化测试和集成结束后,不一定会自动部署。如果有自动部署,则是持续部署的概念了。持续部署 (continuous deployment)持续部署(continuous deployment)则是持续交付的下一步,代码通过评审,自动化部署到生产环境。其目的时可以随时部署,迅速投入生产阶段。持续部署这一步,意味着产品和观众见面,但是要通过重重考验,测试、构建、部署等步骤,而且每一步都是自动的。流程通常如下几步:1. 提交就是常见的代码提交到 CODING 仓库2. 单元测试这个过程 通常是一个针对 commit 操作的钩子,只要由提交,就会跑自动化测试,测试通过才可以推代码到主干。(这轮测试至少要有单元测试)常见测试:单元测试:针对函数或模块的测试集成测试:针对整体产品的某个功能的测试,也叫功能测试端对端测试:从用户界面直达数据库的全链路测试3. 构建第一轮测试通过,代码可以成功合并到主干,交付。那么接下来,就要构建(build),进入第二轮测试。但是,构建并不是绝对必须的过程,构建就是为了让源码变成可以运行的程序或代码。如果是 java、golang 项目,通常要 build 后才可以运行。但如果是 php、python,可能并没有构建过程,只要更新代码到对应的 cgi 容器的工程目录就可以了。构建过程,我们可以自己写一些脚本和接口,挂到对应的钩子里。当然,也可以用一些成熟的构建工具:jenkins (开源免费)Traviscodeship (开源免费)Strider「CODING 持续集成」4. 全面测试这轮测试 ,应该是一次全面测试,除了前面提到的自动化测试,还应该包含一些无法自动化测试的部分。如果第一轮测试已经很全面(意味着前一步和第一轮测试合并了,不构建,自然无法全面测试),那么这轮测试可以作为第一轮测试的补集存在。这里需要注意的是,测试的覆盖率。每次版本更新,更新点都应测试到位。要素统一的代码库自动构建自动测试每个人每天都要向代码库主干提交代码每次代码递交后都会在持续集成服务器上触发一次构建保证快速构建模拟生产环境的自动测试每个人都可以很容易的获取最新可执行的应用程序每个人都清楚正在发生的状况自动化的部署原则所有的开发人员需要在本地机器上做本地构建,然后再提交的版本控制库中,从而确保他们的变更不会导致持续集成失败。开发人员每天至少向版本控制库中提交一次代码。开发人员每天至少需要从版本控制库中更新一次代码到本地机器。需要有专门的集成服务器来执行集成构建,每天要执行多次构建。每次构建都要 100% 通过。每次构建都可以生成可发布的产品。修复失败的构建是优先级最高的事情。测试是未来,未来是测试小结从开发到上线,整体流程:持续集成——>持续交付——>持续部署可以用「CODING 持续集成」进行实践。Jenkins 和持续集成什么关系Jenkins 是一个开源软件项目,是基于 Java 开发的一种持续集成工具,用于监控持续重复的工作,旨在提供一个开放易用的软件平台,使软件的持续集成变成可能。没错,它就是一个具体的持续集成解决方案。基于 Java 实现。可以实现:持续版本发布/测试;监控外部调用执行的工作;持续集成和 webhook 什么关系说到这里,一些有 php 开发经验的小伙伴很容易联想到写 webhook。没错,php 程序通常由 Http Server(比如 apache2、nginx 等)通过反响代理 fpm-cgi 或者直接内置 cgi 来执行 php 程序。这个过程更像是直接请求了 html 文档。说这里是因为,一些 php 写手为了方便更新线上代码,并不想每次都手动 scp 命令上传新的代码,特别时有时候有些代码可能是有问题的。这时候,大家都想到用版本管理,git 就是很好的选择,其中 github 和 CODING 都是不错的选择。我们的话题是持续集成,为什么会突然扯到 php 和 git 呢?那是因为,github 和 CODING 很早就都支持了 webhook 功能。换句话说,我们可以通过开放一个特别的接口,这个接口就一个功能,执行一系列操作,每当接口被调用时,接口可以执行我们预设好的一系列任务指令。这样,我们每次写好代码,只要 push 到仓库,触发 webhook,github 等平台就会去请求我们开放的接口,用来执行更新代码和重启服务等操作。简单说,我们给服务器上留了一个“小工”,指派给他一个接头人,接到信号就做预先安排好的事儿。这个过程,是不是很像持续部署最后自动部署的阶段?没错,就是这样,这个过程很可能时没有自动测试环节,直接自动交付,自动部署。当然,如果 webhook 写复杂点,完全可以配合一些脚本命令做自己的一套 CICD。总结CODING 是一个面向开发者的云端开发平台,提供 Git/SVN 代码托管、任务管理、在线 WebIDE、Cloud Studio、开发协作、文件管理、Wiki 管理、提供个人服务及企业服务,其中实现了 DevOps 流程全自动化,为企业提供软件研发全流程管理工具,打通了从团队构建、产品策划、开发测试到部署上线的全过程。「CODING 持续集成」集成了 Jenkins 等主流企业开发流程工具。 ...

February 20, 2019 · 1 min · jiezi

基于 CODING 的 Spring Boot 持续集成项目

本文作者:CODING 用户 - 廖石荣持续集成的概念持续集成(Continuous integration,简称 CI)是一种软件开发实践,即团队开发成员经常集成他们的工作,通常每个成员每天至少集成一次,也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建(包括编译,发布,自动化测试)来验证,从而尽早地发现集成错误。持续集成的模式如图所示:CI 过程:代码编写 -> 源代码库(GitHub or gitlab)-> CI 服务器(代码构建、自动化测试、结果反馈【构建结果】)涉及 CI 工具:Jenkins、Travis CI、TeamCity、Gitlab CI、CircleCI、Codeship 等,相关资料可以查询对应的官网,其中应用广泛的 Jenkins 和 Travis CI,市场上也推出了智能化的持续集成服务商,比如「CODING 持续集成」,它是基于 Jenkins 配置集成服务,真正实现了一键提交代码,持续集成,部署服务。持续集成的优点1.解放了重复性劳动。自动化部署工作可以解放集成、测试、部署等重复性劳动,而机器集成的频率明显比手工高很多。2.更快地修复问题。持续集成更早的获取变更,更早的进入测试,更早的发现问题,解决问题的成本显著下降。3.更快的交付成果。更早发现错误减少解决错误所需的工作量。集成服务器在构建环节发现错误可以及时通知开发人员修复。集成服务器在部署环节发现错误可以回退到上一版本,服务器始终有一个可用的版本。4.减少手工的错误。在重复性动作上,人容易犯错,而机器犯错的几率几乎为零。5.减少了等待时间。缩短了从开发、集成、测试、部署各个环节的时间,从而也就缩短了中间可以出现的等待时机。持续集成,意味着开发、集成、测试、部署也得以持续。6.更高的产品质量。集成服务器往往提供代码质量检测等功能,对不规范或有错误的地方会进行标致,也可以设置邮件和短信等进行警告。持续集成服务的选择关于网上集成服务的工具很多,其中尤其以 Jenkins 服务最受欢迎,但是 Jenkins 服务需要在自己服务器上进行配置安装,以及安装各种插件,对于刚上手的小白来说,可能存在一定的门槛,操作步骤繁多,操作不够智能,不是真正的自动化运维,缺少一键发布构建服务。所以我们选择了「CODING 持续集成」。CODING 提供的集成服务是什么「CODING 持续集成」是基于 Jenkins 的,兼容 Jenkinsfile 配置文件,如果您之前有使用过或者写过 Jenkinsfile 相信您会很快上手。如何使用CODING持续集成服务「CODING 持续集成」是基于 Jenkins 的,通过 Jenkinsfile 配置文件完成 CI 的步骤,接下来将引导您一步步创建一个持续集成示例。登录 CODING,进入项目中心,点击左边菜单集成服务,开通集成服务,配置完成之后会手动触发第一次构建过程。找到或者创建 Jenkinsfile,如果你对于 Jenkins 比较熟悉的话,可以自己编写 Jenkinsfile 配置文件,也可以采用 CODING 提供的模板文件,如下我就采用了 Jenkinsfile 模板文件来实行自动化持续集成服务,您可以在修改 Jenkinsfile 的时候修改触发方式,您可以自行选择是推送到某个标签或者某个分支时间触发构建。Jenkins 以及能够为 agent 默认配置好 timezone 和 localtime (默认中国上海)。配置好 Jenkinsfile 文件以及配置好环境变量,点击保存,便可以进行持续集成项目了。如图所示,集成步骤分为拉取代码-》构建-》测试-》部署等步骤,点击每个步骤可以看到相应的命令执行情况,下面来一个一个步骤配合 Jenkinsfile 文件解释命令的一些执行情况:代码工程结构如图所示:1.检出项目,如下所示 Jenkinsfile 配置文件第一步通过 Git 检出在远程仓库分支的代码,至于哪个分支可以通过环境变量配置读取 REF 这个环境变量stage(“检出”) { steps { sh ‘ci-init’ checkout( [$class: ‘GitSCM’, branches: [[name: env.GIT_BUILD_REF]], userRemoteConfigs: [[url: env.GIT_REPO_URL]]] ) } }如上图所示,第一步主要是执行从 Git 仓库远程拉取代码,所以命令都是 Git 里面的,包括读取 Git 配置的环境变量包括更新 Jenkinsfile 文件2.构建项目,如下命令所示构建这一步主要是初始化代码和打包代码,因为我们这个工程是以 Java 为主要开发语言,所以重点关注 Java 版本和安装 Maven 命令即可打包,目前 CODING 提供的语言环境包括了 java-1.8.0_181, go-1.7.4, node-10.11.0, php-7.0.30, ruby-2.3, python-2.7.13 等。如有需要可以联系客服开通其它语言环境。stage(“构建”) { steps { echo “构建中…” sh ‘go version’ sh ’node -v’ sh ‘java -version’ // sh ‘php -v’ // sh ‘python -V’ // sh ‘gcc -v’ // sh ‘make -v’ // 请在这里放置您项目代码的单元测试调用过程,例如: sh ‘mvn clean’ // mvn 清除缓存 sh ‘mvn install’ // 构建 Maven 工程 // sh ‘make’ // make 示例 echo “构建完成.” // archiveArtifacts artifacts: ‘**/target/.jar’, fingerprint: true // 收集构建产物 } }因为这个 SpringBoot 项目是以 Java 为主的项目,所以在 Jenkinsfile 文件命令里面其实可以把其它语言的检查版本命令去掉,只需要执行 java -version 命令即可。第一次构建失败:如上图所示,第一次执行执行构建 jar 包失败,因为在本地可以正常 mvn install,所以起初我百思不得其解,上网找了很多资料,经过多番查找,最后在 Stack Overflow 找到了答案,这是由于 OpenJDK 1.8.0_181 这个版本中存在的一个 bug 所致,原文如下:链接,最终解决方案采用更改 pom.xml 文件:<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-surefire-plugin</artifactId> <configuration> <useSystemClassLoader>false</useSystemClassLoader> <skipTests>true</skipTests> </configuration></plugin>成功构建结果如下:3.测试项目,如下所示,我们 SpringBoot 工程通过 mvn test 测试命令即可,比如下面我们测试其中一个用户信息相关的单元测试:stage(“测试”) { steps { echo “单元测试中…” // 请在这里放置您项目代码的单元测试调用过程,例如: sh ‘mvn test -Dtest=com.my.segmentfault.website.Pwdtest’ //测试其中一个单元测试 echo “单元测试完成.” } }第一次失败测试结果如下:后来经检查,是单元测试代码其中存在 bug,修正之后,正确的第二次测试结果如下:4.部署项目,如下所示,部署项目命令可以执行自己写的部署脚本文件。各位可以结合自己项目的真实环境,编写简单的部署脚本,比如上传 jar 包到服务器,然后通过 java - jar XXXX.jar 包执行方式,以及上传 war 包到 tomcat 服务器,然后启动 tomcat 服务器等,也可以结合自己公司项目需要编写复杂的执行脚本文件,然后调用执行脚本命令,比如下面举一个简单的执行脚本例子。部署命令:stage(“部署”) { steps { echo “部署中…” sh ‘./deploy.sh start’ // 启动 tomcat 服务 // sh ‘./deploy.sh stop’ // 停止 tomcat 服务 echo “部署完成” } }deploy.sh 脚本:(其中一些 tomcat 服务路径配置根据自己需要进行修改)#!/bin/bash tomcat_home=/usr/tomcat/apache-tomcat-8.0.48 //修改为自己服务器的 tomcat 路径SHUTDOWN=$tomcat_home/bin/shutdown.sh STARTTOMCAT=$tomcat_home/bin/startup.sh case $1 instart) echo “启动$tomcat_home”$STARTTOMCAT ;; stop) echo “关闭$tomcat_home”$SHUTDOWN pidlist=ps -ef |grep tomcat |grep -v "grep"|awk '{print $2}' kill -9 $pidlist #!/bin/bash tomcat_home=/usr/tomcat/apache-tomcat-8.0.48 SHUTDOWN=$tomcat_home/bin/shutdown.sh STARTTOMCAT=$tomcat_home/bin/startup.sh case $1 instart) echo “启动$tomcat_home”$STARTTOMCAT ;; stop) echo “关闭$tomcat_home”$SHUTDOWN pidlist=ps -ef |grep tomcat |grep -v "grep"|awk '{print $2}' kill -9 $pidlist stop) echo “关闭$tomcat_home”$SHUTDOWN pidlist=ps -ef |grep tomcat |grep -v "grep"|awk '{print $2}' kill -9 $pidlist #删除日志文件,如果你不先删除可以不要下面一行 rm $tomcat_home/logs/ -rf #删除tomcat的临时目录 rm $tomcat_home/work/* -rf ;; restart) echo “关闭$tomcat_home”$SHUTDOWN pidlist=ps -ef |grep tomcat |grep -v "grep"|awk '{print $2}' kill -9 $pidlist #删除日志文件,如果你不先删除可以不要下面一行 rm $tomcat_home/logs/* -rf #删除tomcat的临时目录 rm $tomcat_home/work/* -rf sleep 5 echo “启动$tomcat_home”$STARTTOMCAT #看启动日志 #tail -f $tomcat_home/logs/catalina.out ;; logs) cd /mnt/alidata/apache-tomcat-7.0.68/logstail -f catalina.out ;; esac 服务启动展示系统主页如下图所示:文章详情如下图所示:归档页面如下图所示:系统后台管理如图所示:总结CODING 是一个面向开发者的云端开发平台,提供 Git/SVN 代码托管、任务管理、在线 WebIDE、Cloud Studio、开发协作、文件管理、Wiki 管理、提供个人服务及企业服务,其中实现了 DevOps 流程全自动化,为企业提供软件研发全流程管理工具,打通了从团队构建、产品策划、开发测试到部署上线的全过程。「CODING 持续集成」集成了 Jenkins 等主流企业开发流程工具,如上所示,这个以 SpringBoot 打造的 CMS 社区系统便可以在 CODING 上面实现团队协作开发,一键部署作为团队以及公司文档共享社区论坛等作用。本文适量引用:“持续集成”词条的百度百科 ...

February 20, 2019 · 2 min · jiezi

致 CODING 用户的元宵问候

元宵快乐!感谢您一直以来对 CODING 的理解与支持。2019 年 CODING 也走入了创业的第五个年头,为了将“让开发更简单”的愿景落地,我们做了许多探索,产品完成度也在不断提高,这其中离不开您的反馈与鞭策,值此元宵佳节之际,向您阐述 CODING 研发管理系统的产品理念与发展蓝图。软件工程日益复杂,企业到底需要什么样的工具?随着中国企业的数字化转型不断深入,更多的客户对软件工程提出了更加复杂的需求,软件工程已经变成了涉及多个角色和复杂步骤的大型工程。目前来说,开发团队想要做正常运转,往往会需要配置复杂的工具组合。软件开发不同环节可选工具示例这让我们意识到提供单一工具带来的价值提升有限,无法从整体效率上帮助到软件开发团队。同时,工具组合起来后,工具间的信息流转也成了大问题。如图所示,一段代码从生产到上线的整个过程中涉及到 9 种身份和 16 个步骤。一个典型的软件开发流程图围绕一段代码的修改,下游的人需要获取足够的信息才能开始工作,上游的人需要了解流程的进度和下游的反馈。产品经理提出了需求之后,想要追踪需求的进度会非常困难,很难知道代码是不是完成了,测试有没有通过,或者是不是已经上线了。同理,写代码的人也无法知道自己编写的代码走到了哪个地步,整个流程的信息传递依赖于流程上的每个人主动的进行信息反馈。而流程中每增加一个人,信息传达的成本将会有指数级的增加,信息同步的问题在团队规模扩大的过程中愈发凸显。CODING 希望提供全套的软件研发流程管理系统,无需配置多种工具组合,并且上下游的信息可以做到记录和打通。真正解决企业的软件研发效能问题。CODING 研发管理系统 2019 产品目标基于为客户提供打通全流程信息的产品蓝图, CODING 研发管理系统在 2019 年的主要产品目标为:提供完整的工具体系工具体系间信息的完全流转目前 CODING 研发管理系统 已经上线或在内测的产品模块有:需求管理、代码管理、测试管理、缺陷管理、持续集成、文件管理。同时,将在 2019 年年中上线构建物管理、部署管理、部署管理及数据分析模块。CODING 研发管理系统当前产品阶段2019 年下半年,在功能模块逐步完善的同时,我们也将增加模块间信息流转的机制,形成可视化的研发流水线,追踪每段代码的“来龙去脉”。现阶段 CODING 项目统计视图持续渴求您的诉求与建议CODING 研发管理系统是一套复杂的产品体系,放眼国内外,也很难找到产品借鉴。CODING 团队在摸索过程中得到了许多客户的支持。客户的诉求促使我们对软件工程产生更多的思考。点击快速体验 CODING 研发管理系统,一键开启研发管理新时代。如果您在使用中有任何意见或建议,可以通过以下方式联系我们:客户支持邮箱:enterprise@coding.net客户支持电话:400-930-9163CODING CEO 张海龙

February 19, 2019 · 1 min · jiezi

使用 CODING 进行 Hexo 项目的持续集成

本文作者:CODING 用户 - 廖石荣关于持续集成的概念持续集成指的是,频繁地(一天多次)将代码集成到主干。持续集成的过程如图所示:CI 过程:代码编写 -> 源代码库(GitHub or gitlab)-> CI 服务器(代码构建、自动化测试、结果反馈【构建结果】)涉及 CI 工具:Jenkins、Travis CI、TeamCity、Gitlab CI、CircleCI、Codeship 等,相关资料可以查询对应的官网,其中应用广泛的 Jenkins 和 Travis CI,Gitlab CI 是开源的 Rails 项目 GitLab 的一个组成部分,GitLab CI 能与 GitLab 完全集成,可以通过使用 GitLab API 轻松地作为项目的钩子。关于持续集成的优点快速发现错误。每完成一点更新,就集成到主干,可以快速发现错误,定位错误也比较容易。防止分支大幅偏离主干。如果不是经常集成,主干又在不断更新,会导致以后集成的难度变大,甚至难以集成。持续集成服务的选择关于网上集成服务的工具很多,其中尤其以 Jenkins 服务最受欢迎,但是 Jenkins 服务需要在自己服务器上进行配置安装,以及安装各种插件,对于刚上手的小白来说,可能存在一定的门槛,操作步骤繁多,操作不够智能,不是真正的自动化运维,缺少一键发布构建服务。所以我们选择了「CODING 持续集成」。CODING 提供的集成服务是什么CODING 推出的持续集成服务,「CODING 持续集成」是基于 Jenkins 的,兼容 Jenkinsfile 配置文件,如果您之前有使用过或者写过 Jenkinsfile 相信您会很快上手。如何使用 CODING 持续集成服务「CODING 持续集成」是基于 Jenkins 的,通过 Jenkinsfile 配置文件完成CI的步骤,接下来将引导您一步步创建一个持续集成示例。登录 coding,进入项目中心,点击左边菜单集成服务,开通集成服务,配置完成之后会手动触发第一次构建过程找到或者创建 Jenkinsfile,如果你对于Jenkins 比较熟悉的话,可以自己编写 Jenkinsfile 配置文件,也可以采用CODING 提供的模板文件,如下我就采用了Jenkinsfile 模板文件来实行自动化持续集成服务,您可以在修改 Jenkinsfile 的时候修改触发方式,您可以自行选择是推送到某个标签或者某个分支时间触发构建。jenkins 以及能够为 agent 默认配置好 timezone 和 localtime(默认中国上海)配置好 Jenkinsfile 文件以及配置好环境变量,点击保存,便可以进行持续集成项目了如图所示,集成步骤分为拉取代码-》构建-》测试-》部署等步骤,点击每个步骤可以看到相应的命令执行情况,下面来一个一个步骤配合 Jenkinsfile 文件解释命令的一些执行情况:1.检出项目,如下所示 Jenkinsfile 配置文件第一步通过 Git 检出在远程仓库分支的代码,至于哪个分支可以通过环境变量配置读取 REF 这个环境变量stage(“检出”) { steps { sh ‘ci-init’ checkout( [$class: ‘GitSCM’, branches: [[name: env.GIT_BUILD_REF]], userRemoteConfigs: [[url: env.GIT_REPO_URL]]] ) } }如上图所示,第一步主要是执行从 Git 仓库远程拉取代码,所以命令都是 Git 里面的,包括读取 Git 配置的环境变量包括更新 Jenkinsfile 文件2.构建项目,如下命令所示构建这一步主要是初始化代码和打包代码,因为我们这个工程是以 Node.js 为主要开发语言,所以重点关注 Node.js 版本和 安装 hexo 脚手架命令即可打包,目前Coding 提供的语言环境包括了 java-1.8.0_181, go-1.7.4, node-10.11.0, php-7.0.30, ruby-2.3, python-2.7.13 等。如有需要可以联系客服进行开通其它语言环境。stage(“构建”) { steps { echo “构建中…” sh ‘go version’ sh ’node -v’ sh ‘java -version’ sh ‘php -v’ sh ‘python -V’ sh ‘gcc -v’ sh ‘make -v’ // 请在这里放置您项目代码的单元测试调用过程,例如: // sh ‘mvn package’ // mvn 示例 // sh ‘make’ // make 示例 sh ’npm install -g hexo-cli’ //安装hexo 脚手架 echo “构建完成.” // archiveArtifacts artifacts: ‘**/target/.jar’, fingerprint: true // 收集构建产物 } }因为这个 Hexo 项目是以 Node.js 为主的项目,所以在 Jenkinsfile 文件命令里面其实可以把其它语言的检查版本命令去掉,只需要执行 node - v 命令即可3.测试项目,如下所示,如果是 maven 项目可以通过 mvn 命令执行测试语句,我们 Hexo 这个工程通过 hexo 脚手架构建测试命令即可,如果单元测试不通过则会显示不通过,(hexo 对文件格式存在要求,如果文件格式不符合正规 MarkDown 语法,则会抛出错误)stage(“测试”) { steps { echo “单元测试中…” // 请在这里放置您项目代码的单元测试调用过程,例如: sh ‘hexo clean’ //清除缓存 sh ‘hexo g ’ // 将 md 文件构建为 html 页面示例 echo “单元测试完成.” // junit ’target/surefire-reports/.xml’ // 收集单元测试报告的调用过程 } }*正确构建测试结果如下图:4.部署项目如下所示,部署项目命令可以执行自己写的部署脚本文件,也可以配置好“_config.yml”文件之后直接执行 hexo 脚手架自带的命令。如下图整个代码结构图:配置文件部分截图:部署命令:stage(“部署”) { steps { echo “部署中…” // 请在这里放置收集单元测试报告的调用过程,例如: // sh ‘mvn tomcat7:deploy’ // Maven tomcat7 插件示例: // sh ‘./deploy.sh’ // 自研部署脚本 sh ’npm install hexo-deployer-git –save’ // 安装 deploy 脚手架 sh ‘hexo deploy’ // 部署 echo “部署完成” } }服务启动展示系统主页,可以作为团队以及小型公司共享文件的社区论坛,hexo 构建速度快,采用纯静态框架,语法采用纯markdown 语言,适合编写文档。页面详情,可以通过配置是否开启评论功能以及可以添加赞赏功能,并且可以统计字数,建议时长等功能,分类标签等适合文档归集等功能总结CODING 是一个面向开发者的云端开发平台,提供 Git/SVN 代码托管、任务管理、在线 WebIDE、Cloud Studio、开发协作、文件管理、Wiki 管理、提供个人服务及企业服务,其中「CODING 企业版」实现了 DevOps 流程全自动化,为企业提供软件研发全流程管理工具,打通了从团队构建、产品策划、开发测试到部署上线的全过程。 集成了 Jenkins 等主流企业开发流程工具,如上所示,这个 Hexo 博客便可以在 CODING 上面实现团队协作开发,一键部署作为团队以及公司文档共享社区论坛等作用。本文适量引用:阮一峰的博客 ...

February 13, 2019 · 2 min · jiezi

使用 CODING 进行 Spring Boot 项目的集成

本文作者:CODING 用户 - 高文持续集成 (Continuous integration) 是一种软件开发实践,即团队开发成员经常集成他们的工作,通过每个成员每天至少集成一次,也就意味着每天可能会发生多次集成。成员之间的代码相互影响,可能会出现各种编译、运行的错误,为了避免提交代码影响到其他开发者,每次集成都通过自动化的构建(包括编译,发布,自动化测试)来验证,从而尽早地发现错误,使得开发过程更加简单方便。通用的持续集成流程大体是像上图所示一样,借助 Jenkins 连通 Git 与 Docker 镜像仓库,为后续的持续部署做准备。而在「CODING 持续集成」中,可以省去其中很多环境部署的麻烦事,下面说一下我在 CODING 平台做的持续集成工作。我与 CODING 之缘CODING 是国内首个一站式云端软件服务平台,致力于通过技术创新推动软件开发升级转型,让开发更简单。将代码托管、项目管理、Cloud Studio、一键部署等开发工具集成到浏览器中,免除繁杂的开发环境部署,降低软件开发部署成本。最初了解 「CODING」 ,是我在开发微信小程序时,腾讯云推荐托管代码到 CODING 上,于是注册了一个 CODING 账号。开始使用时,主要以Web版开发工具为主,觉得只是一个 Eclipse 的 Che 版本,当时也自己部署一个 Eclipse 的 Che 版本。但部署 Che 版本时,才发现, CODING 其实比 Che 好用得不是一点半点。流畅性、易用性已经高出 Che 一个等级了,功能上也比 Che 更丰富。后来逐渐用起来了,发现 「CODING」 不只是 WebIDE ,还是 Git 、 Jenkins 、 Wiki 、敏捷开发工具、项目管理工具……现在持续集成功能出来了,可以免费试用15天,于是注册一个玩一玩。wencst 的个人主页「CODING 持续集成」基础操作首先需要创建企业账号;然后创建自己的项目;进入项目维护项目代码。本文所使用的源代码为本人开源的自动开发框架。Git 操作下面为 Git 的操作了,相信看文章的大部分人可以略过这一步。详细的 Git 步骤可以参考:《 CODING 中的 Git 操作》Git 操作主要为后续持续集成操作的触发器。持续集成持续集成操作的设置相对比较简单,按照提示一步步下来即可。有一块需要注意的,就是构建所用的分支,在配置持续集成时,需要选择构建触发方式,触发时间(代码上传时触发/手动触发),以及完成时邮件发送提醒(提醒触发者/不做任何事/只有失败时提醒)。对于多分支代码工程一定要注意,选择自己所需的配置。我这里所用的为系统默认配置,即当有人提交代码至 master 时触发构建,完成时总是发邮件提示开发者。「CODING 持续集成」提供了三套不同的 Jenkinsfile 模板供开发者使用:简易模板、并行模板、自定义模板。我这里选用简易模板,并稍作修改。pipeline { agent { label “default” } stages { stage(“检出”) { steps { sh ‘ci-init’ checkout( [$class: ‘GitSCM’, branches: [[name: env.GIT_BUILD_REF]], userRemoteConfigs: [[url: env.GIT_REPO_URL]]] ) } } stage(“构建”) { steps { echo “构建中…” sh ‘mvn clean install’ echo “构建完成.” archiveArtifacts artifacts: ‘/target/*.jar’, fingerprint: true // 收集构建产物 } } stage(“Docker”) { steps { echo “Docker镜像生成中…” sh ‘cd wencst-generatorJPA/target && cp classes/Dockerfile . && docker build -t wencst/wencst-generatorJPA .’ echo “镜像生成完成.” sh ‘docker push wencst/wencst-generatorJPA’ echo “镜像上传完毕” } } } }更新 Jenkinsfile 后,代码 push 到对应的分支上,会自动执行构建,发现构建失败。点开后,查看构建失败的具体原因,输出与 maven 编译时输出的没有什么差别。原因提示: there is no POM in this directory。原来我中间还有一层目录,需要进入目录后才能编译。pipeline { agent { label “default” } stages { stage(“检出”) { steps { sh ‘ci-init’ checkout( [$class: ‘GitSCM’, branches: [[name: env.GIT_BUILD_REF]], userRemoteConfigs: [[url: env.GIT_REPO_URL]]] ) } } stage(“构建”) { steps { echo “构建中…” sh ‘cd wencst-generatorJPA && mvn clean install’ echo “构建完成.” archiveArtifacts artifacts: ‘/target/.jar’, fingerprint: true // 收集构建产物 } } stage(“Docker”) { steps { echo “Docker镜像生成中…” sh ‘cd wencst-generatorJPA/target && cp classes/Dockerfile . && docker build -t wencst/wencst-generatorJPA .’ echo “镜像生成完成.” sh ‘docker push wencst/wencst-generatorJPA’ echo “镜像上传完毕” } } } }提交代码后,会自动执行构建。可以显示程序编译过程,可以显示每一步详细输出,可以增加状态徽标到相应的文档或网页中。可以说「CODING 持续集成」 想的是比较周到的,基本集成了绝大部分开源系统中相应的职能。构建使用默认的 https://repo.maven.apache.org 源,构建速度也还可以。至此持续集成完成,界面清晰整洁,并且可以对测试报告和构建结果进行下载,构建过程也会发邮件给相关人员。确实让开发更简单了。以前在做这一系列工作时,架构师起码要做几件事情:1.搭建 git 仓库2.搭建 jenkins3.在 git 仓库中增加 CI 配置4.邮箱配置「CODING 持续集成」为开发者省去了很多工作,除了构建过程中必要的工作以外,其他的基本一键搞定,不用关心各个组件的安装配置,环境情况,网络情况,存储备份等内容。Jenkinsfile 拆解重点解释一下 stages 部分,整体分为三个 stages:第一步为代码检出 stage(“检出”) { steps { sh ‘ci-init’ checkout( [$class: ‘GitSCM’, branches: [[name: env.GIT_BUILD_REF]], userRemoteConfigs: [[url: env.GIT_REPO_URL]]] ) } }这一步检出项目中的代码到 jenkins 的 workspace 目录下,这一步是 「CODING 持续集成」 默认的配置,无需过多解释。第二步为编译构建 stage(“构建”) { steps { echo “构建中…” sh ‘cd wencst-generatorJPA && mvn clean install’ echo “构建完成.” archiveArtifacts artifacts: ‘**/target/.jar’, fingerprint: true } }这一步是执行代码编译,我所用的是 maven 编译 spring boot 工程, 「CODING 持续集成」 集成了 mvn 命令,可以直接执行 maven 操作。注意: jenkins 执行 sh 命令的根路径都是在当前 workspace 下,所以切换路径与 maven 编译命令要在同一个 sh 命令下。编译执行后,收集编译的产物,archiveArtifacts artifacts: ‘**/target/*.jar’, fingerprint: true这一步的意思是,将所有工程的 target 路径下的 jar 包都算作工程产物。第三步为 docker 镜像生成 stage(“Docker”) { steps { echo “Docker镜像生成中…” sh ‘cd wencst-generatorJPA/target && cp classes/Dockerfile . && docker build -t wencst/wencst-generatorJPA .’ echo “镜像生成完成.” sh ‘docker push wencst/wencst-generatorJPA’ echo “镜像上传完毕” } } 对于熟悉 docker 的人并不是很陌生,依旧使用 shell 命令来执行 docker build 操作。cd wencst-generatorJPA/target 首先切换路径到 jar 包所在目录。cp classes/Dockerfile . 拷贝 Dockerfile 到当前路径下。docker build -t wencst/wencst-generatorJPA . 执行 docker build 操作,用以创建 docker 镜像。docker push wencst/wencst-generatorJPA 将创建出来的 docker 镜像上传到 dockerhub 中去。总结整体来说 「CODING 持续集成」 想的很周全了,无论从易用性、美观度以及人性化角度上来说,做得都非常不错。下面着重说说我使用 「CODING 企业版」 的持续集成后的感受:满足了从开发到代码管理,到代码集成,到单元测试,甚至到后续部署,一站式管理;配置相对简单,只需配置 Jenkinsfile 即可完成,无需花费大量的人力物力来做各系统间的整合操作;系统集成后,会给开发人员发送邮件,报告集成成功或失败,这一点还是比较人性化的;「CODING 持续集成」平台集成了很多种命令,起码我用到的 mvn/java/docker/git 这一类的命令基本都集成在服务中了。希望 CODING 会越来越完善,越来越好! ...

February 13, 2019 · 2 min · jiezi

SegmentFault 助力 Cloud Studio 插件评选大赛

@CODING 和 腾讯云 ( @腾讯云加社区 )长期以来都是 SegmentFault 社区良好的开发者合作伙伴,他们也一直致力于通过优质的开发者产品服务好广大的开发者。此次非常感谢 Coding 选择通过 SegmentFault 平台向广大社区开发者发布这次 Cloud Studio 插件评选大赛。首先先给大家介绍一 Cloud StudioCloud Studio 是基于浏览器的集成式开发环境,为开发者提供了一个永不间断的云端工作站。不管有没有开发经验都可以毫无门槛的体验云端开发的乐趣,支持绝大部分编程语言,包括 HTML5、PHP、Python、Java、Ruby、C/C++、.NET、小程序等等。Cloud Studio 提供了完整的 Linux 环境,并且支持自定义域名指向,可以完成各种应用的开发编译与部署。立即访问 Cloud Studio https://studio.dev.tencent.com如何参与此次插件大赛注册并登陆腾讯云(https://cloud.tencent.com)⬇︎设置腾讯云开发者平台账号密码⬇︎点击进入活动页面⬇︎ 点击进行插件的编写与提交(需要选择参与评选的类别)⬇︎审核无误后即可上架自动参与评选此次插件大赛围绕 Git、实用小工具、腾讯云产品对接、UI 强化、语言支持等 14 个主题设立了大奖,同时也设立最具娱乐奖,代码最简单奖,设置功能最复杂奖等娱乐性奖,共近三十种奖项,无论从创意,实用,或娱乐角度,总有一款奖项适合你!11 月 19 日:大赛开始12 月 1 日:开始评分抽奖12 月 20 日:提交及评分截止12 月 25 日:获奖公示及奖品发放欢迎广大开发者踊跃参赛,奖品丰厚,更多信息可以查看此次大赛官网:https://studio.dev.tencent.co…

November 20, 2018 · 1 min · jiezi