Coding.net

https://help-assets.codehub.c...

在我的项目协同中能做的不仅仅只有简略的图文记录，更重要的是切实为软件研发场景削减高效会议能力。在事项合作中一键发动会议，对齐上下游卡点，畅享高效合作。 快来体验吧！ 腾讯会议利用市场全新上线# #会·得新应手

中化信息技术有限公司，简称“中化信息”，是世界 500 强企业中国中化控股有限责任公司（简称“中国中化”）的全资直属公司，依靠于中国中化的信息化建设实际，建设起从征询、设计到研发、交付及运维的服务价值链，造成涵盖生命科学、材料科学、根底化工、环境迷信、轮胎橡胶、机械装备、城市经营、产业金融等行业业务利用及翻新利用的 17 条产品线及解决方案，致力于通过施展信息科技的驱动与赋能作用，助力中国中化成为世界一流的综合性化工企业。 “线上中化”策略推动，更强韧的 IT 能力成为刚需进入工业 4.0 时代，信息技术浸透至各行各业，产业数字化应运而生。通过互联网革新，传统企业可能买通产业链上下游，使设施、工厂、供应商、产品和消费者严密地连贯和交融，以智能化、数字化的形式为消费者提供更高品质的服务体验，打造更高价值的产业生态，构建弱小的数字生态系统。 产业数字化转型的红利诚然可观。为此，中国中化提出了“线上中化”的战略目标，鼎力推动公司外部的数字化转型工作，以数字化赋能公司高质量倒退，推动中国中化走向世界一流行业。与此同时，“线上中化”的数字化策略对中化信息的 IT 能力提出了空前挑战。中化信息作为中国中化次要的信息科技平台提供商，肩负 “施展信息科技的驱动与赋能作用，助力中国中化成为世界一流的综合性化工企业” 的使命，必须要一直进步其 IT 能力，继续打造翻新的根底平台和解决方案，以撑持“线上中化”策略的夯实落地。 一站式研效平台建设，撑持研发全流程闭环治理为了从根本上进步本身的 IT 能力，中化信息决定采纳全新的研发管理模式。通过 CODING，中化信息以 DevOps 办法体系为外围打造了新一代数字化研效平台，买通从需要、设计、开发、构建、测试、公布到部署的全流程，造成研发品质监控闭环，实现项目管理可视化、构建集成自动化、继续测试自动化、继续部署自动化，以此来疾速响应业务需要，疾速交付高质量的业务价值。 从麻利方法论开始，围绕「我的项目」的精细化多角色合作凭借 CODING DevOps 平台的多租户治理劣势，中化信息依据产品或业务需要组建多个我的项目，再将须要合作的各方增加至对应我的项目，以此发展精细化的团队合作。以「我的项目」为单位，中化信息对人员权限和资源进行了对立的治理，让公司外部实现了产品/项目经理、利用架构师、开发人员、测试人员和运维人员等不同角色在一个平台内高效合作。 CODING DevOps 平台承载业界先进的麻利 Scrum 实践，提供弱小灵便的项目管理性能，包含迭代布局、需要合成、状态流转、看板视图跟踪等等，帮忙中化信息在公司外部疾速落地麻利项目管理模式。 依据研发团队既定的工作流程和模式，中化信息自主定义了我的项目中的需要、工作、缺点等事项类型的属性及工作流，同时还通过全局我的项目协同配置对全团队实现了规范性治理，极大晋升了跨角色、跨部门的合作效率。 代码对立治理，企业外围资产更平安我的项目内多仓库集中管控中化信息外部共有多达上百个仓库，且同时应用了 Git 和 SVN 两种版本控制系统，难以进行无效的对立治理。CODING 提供疾速稳固的 Git/SVN 代码托管服务，并提供简略易用的内部仓库（如 GitLab、GitHub 等常见内部仓库）导入性能，帮忙中化信息将原有的 SVN/Git 代码仓库逐渐迁徙至 CODING，实现在单个我的项目内集中管理对应业务团队的所有代码，实现代码资产的对立纳管。此外，每个代码仓库均反对独自的权限配置，让中化信息在集中管理代码之余，也保留了不同仓库差异化治理的灵活性。 面向平安的代码扫描应用 CODING 前，中化信息外部次要通过人工审查发现代码安全漏洞，但人工的形式百密终有一疏，且消耗较多的人力。CODING DevOps 平台自带的代码扫描性能集成了 CheckStyle、FindBugs、SonarQube 等几十种工具、数千条规定，反对包含 Java、C/C++、JavaScript、Python、Go、PHP、Ruby 等十余种支流语言，高效代替了中化信息研发人员的人工操作。在开发人员提交代码之后，CODING 平台会主动剖析代码仓库中的源代码，开掘潜藏的代码缺点、安全漏洞以及不标准代码，并且生成问题列表，给开发人员提供批改倡议。另外，平台也会对代码品质进行度量，统计出构造异样简单的办法及反复代码，帮忙开发人员继续优化改良。 自应用 CODING 以来，中化信息大量且高频地应用 CODING 提供的 Java 代码扫描计划，晋升了代码的稳定性和可维护性，极大地改善了团队的研发效力。 ...

首期 Techo Day 腾讯技术开放日将于明天 9 点 45 分在线上拉开帷幕！ 本期主题“轻量级云开发与云利用”，在「架构与原理」专场，您将看到 CODING DevOps、Lighthouse、CVM 等 CSIG 明星开发工具背地技术原理解析；您也将看到来自腾讯云 TVP、腾讯云先锋、腾讯云合作伙伴英特尔的业余大神，分享其成长故事及心得体会。 实际出真知， Techo Day 还开设了「入手实验室」环节。您将体验到 Cloud Studio、自动化助手 TAT、PAG 等在开发环境的理论利用。实验室采纳了企业微信小班互动的模式，让老师与开发者们在同一实在开发环境中进行实操，实时交换开发我的项目及技术细节，更深刻地了解、更便捷地应用腾讯云的明星工具！ 始终以来腾讯云都致力于为开发者提供更“化繁为简、轻而易用”的工具产品，从而升高开发门槛，进步研发效率。在早晨的「公布与降级」环节，您将看到笼罩云原生、机器学习、数字孪生、物联网等重点赛道的产品专家为大家讲述工具降级优化的理念以及将来愿景！ 此次 Techo Day ，心愿通过腾讯、腾讯云无关技术干货的课程分享与利用工具的入手实际，帮忙开发者晋升研发效力，解决日常工作中的利用所需，也为技术人群的同业交换、技术热点与技术趋势公布提供一个优质的交流平台。

老百姓大药房是中国具备影响力的药品批发连锁企业，中国药品批发企业综合竞争力百强冠军、中国服务业 500 强企业、湖南省百强企业。 自 2001 年创建以来，现已胜利开发了湖南、 陕西、浙江、江苏等 22 个省级市场， 领有门店 8000 多家，全国仓储面积超过 19 万平方米。 数字智联时代，如何更好地服务“老百姓”？随着业务规模不断扩大，老百姓大药房累计会员迫近 6 千万大关，每年服务 1.25 亿忠诚顾客。在数字化时代，尤其是寰球疫情风行的大背景下，消费者对服务体验和品质提出了更高的要求。给消费者提供“更齐全、更和煦、更业余”的服务，既是老百姓大药房“所有为了老百姓”的企业愿景，更是疫情时代关乎民生的企业责任。 在突飞猛进的数字智联时代，如何将线上渠道与线下门店联合，在风云变幻的市场环境中放弃肯定的敏捷性与灵活性？如何以业务需要和价值为外围，对内晋升团队的业务响应能力和工程交付效率，对外晋升服务质量与用户口碑？对于传统批发行业的老百姓大药房来说，麻利转型无疑是最佳答案。 老百姓大药房心愿使用新的工具和规范化的工作流程打造自组织的麻利团队，建立麻利交付理念，造就麻利种子人才，晋升团队的麻利成熟度，从而使研发团队具备疾速试错、验证假如的能力，以助力企业良性、高速倒退。麻利转型，是历史的抉择，也是时代的召唤。 Thoughtworks 后行，从 0 到 1 麻利导入Thoughtworks 在 17 个国家领有业余卓越的跨职能团队，会集了大量策略专家、开发人员、数据工程师和设计师。Thoughtworks 独创“分布式麻利”概念，深知如何集寰球团队之力大规模交付卓越的软件，致力于帮忙客户开启晦涩数字化之路，晋升公司应变能力，引航将来征程。 在对老百姓大药房的研发部⻔现状、职责范畴、组织构造、业务痛点、工作流程、应用工具及技术等背景信息进行深刻调研之后，Thoughtworks 中国区的咨询师制订了基于 CODING 实现的麻利转型打算，分批次、有秩序地在多个试点团队施行麻利导入。 麻利组织架构设计在麻利转型之前，老百姓大药房的业务团队和研发团队在策略上不足协同，业务需要的指标和价值常常无奈很好地传递给研发团队，且跨组合作老本高，存在妨碍。为了更好地晋升业务交付价值，Thoughtworks 领导老百姓大药房建设了以业务价值为外围的跨职能组织构造。纵向为自组织的跨职能小组，蕴含产品经理、 Scrum Master（通常由开发专任）、架构师、开发人员和测试人员等，不超过 10 人。一个跨职能小组对应老百姓大药房的一个具体产品或者业务线，能够残缺交付业务价值，并且能自行决定产品指标和自主决策。灵活机动的小团队模式，便于跨职能成员当面交换和探讨，更好地为独特的业务指标进行合作。 横向为同个职能内的的协同组织，由职能负责人牵头职能内的协同流动，协调跨业务线单干的资源，推动跨团队、跨业务线的合作与改良。 麻利根底培训&实际辅导胜利的实际需以扎实的理论知识为根据。在老百姓大药房外部，少数成员尚未意识到麻利开发和继续交付的价值和必要性，不足一直学习和晋升的踊跃文化与气氛。针对这个问题，Thoughtworks 咨询师通过一系列培训导入麻利价值观和治理实际，笼罩麻利根底概念、产品经理及 Scrum Master 基础知识、DevOps 实际等方方面面，确保老百姓大药房的成员分明地意识到麻利是什么、为什么须要麻利、并通过我的项目实战了解各个角色该如何在团队中施展最大价值。人员赋能：麻利教练造就除了对产品经理和 Scrum Master 进行日常实际辅导培训以外，Thoughtworks 还通过麻利教练训练营的模式帮忙老百姓大药房造就外部教练，以保障麻利转型成果可继续、可推广。在 Thoughtworks 咨询师的率领下，组织内选定的种子选手经验了一系列强化培训、实际辅导及学习分享。最终选定的合格外部教练会带着“践行麻利、推广麻利”的使命，在老百姓大药房组织内作为推动麻利改革的外围力量⻓期存在。用 CODING，打造规范化、可视化、自动化的麻利研发管理体系企业麻利转型，不仅须要思维的转变，还须要通过工具承载麻利的理念和流程。CODING 依靠业界麻利项目管理方法论与 DevOps 体系打造的一站式平台，买通了麻利开发全生命周期的工具链孤岛及合作壁垒，助力老百姓大药房在组织外部打造规范化、可视化、自动化的麻利研发管理体系。 我的项目与我的项目集联动，规范化业务合作在应用 CODING 之前，老百姓大药房组织外部研发团队对业务的透明度无限。业务侧的需要目标、场景和价值传播不分明，往往造成不必要的沟通和了解老本。不通明、无契约的合作造成了业务侧与研发侧无奈造成充沛互信，从而无奈将业务价值最大化。 在应用 CODING 之后，老百姓大药房将原始业务需要对立在我的项目集中进行治理。一个我的项目集对应一个具体产品或业务线，而后通过不同的工作项对该产品/业务线下不同模块的需要进行分类。业务侧依据业务战略规划里程碑，而后在对应的需要分类下创立子工作项，填写具体的需要背景、形容、指标/价值，指定开始/截至工夫，即可实现需要注销。 通过「合成到我的项目」，该业务需要可被产品经理拆分到多个我的项目的用户故事和工作中实现。这对于跨团队、跨业务线单干的场景尤为重要。 业务需要在研发侧的映射是我的项目中的一个个用户故事，是麻利合作流程中的最小工作单元。老百姓大药房组织外部对用户故事的书写进行了严格标准：必须形容分明用户故事和验收条件，并提供必要的细节形容以及产品原型图等信息。用户故事是研发团队合作的根底，将验收条件廓清，能力让产品、开发和测试对“需要是否做好、做对”造成共识，确保团队“心往一处想，劲往一处使”，交付满足预期的业务价值。 ...

百果园（全称深圳百果园实业（团体）股份有限公司），2001 年成立于深圳，是一家集水果洽购、种植反对、采后保鲜、物流仓储、规范分级、营销拓展、品牌经营、门店批发、信息科技、金融资本、科研教育于一体的大型连锁企业。 截至 2021 年 9 月，百果园在国内外布局 200 多个特约供货基地，线下门店超 5000 家，进驻全国 90 多个城市。百果园 APP 下载量冲破 1500 万，小程序注册人数超 4000 万，一体化会员数超 8000 万。通过整整 20 年的品牌经营，这个“全心全意做水果”的连锁龙头企业已在生鲜连锁批发行业构建了规模最大的线上线下一体化店仓网络系统，间断 6 年进入中国连锁百强企业。 数字化新零售业态下，非一体化研发管理体系瓶颈凸显随着线上/线下一体化策略的推动，百果园打造了专属的销售、金融、交易、供应链、营销服务、标准化种植以及数据分析平台，通过智能化与数字化实现人、货、场的结构调整和降级。业务需要激增、用户数量暴涨的同时，我的项目数量呈倍数逐年增长。这也使得多平台、多我的项目的标准化治理难度降级，非一体化研发管理体系瓶颈凸显。 难题一：研发工具及数据扩散割裂，治理及保护老本高在邂逅 CODING 之前，百果园应用不同的零碎来别离治理我的项目事项、托管代码以及积淀团队常识。非一体化的研发管理工具存在弊病，难以撑持百果园在创新型数字化零售业态下多渠道批发业务的增长需要。 因为管理工具扩散，账号及权限管理体系不对立，工具治理存在难度；成员须要在不同的平台之间来回切换，研发效率低下。各工具之间的数据割裂，难以实现代码与我的项目需要的关联。若要实现各工具之间的数据联通，还须要额定的研发老本。多个工具独自保护，保护难度及老本高。 难题二：自研零碎与项目管理平台对接存在妨碍，短少本地技术支持百果园自研的度量审计零碎次要用于度量我的项目内迭代和具体任务的停顿，便于管理者评估各事业线的倒退状况。要实现这一目标，度量审计零碎须要与项目管理平台对接，以获取所需的我的项目数据。 然而，因为百果园所应用的项目管理平台的 Open API 与自研零碎匹配度不高，两者对接上存在艰难，须要定制化开发。除此之外，百果园之前应用的项目管理平台由国外厂商提供，该厂商在国内的技术支持能力欠缺。如何针对实际的业务场景将工具对接疾速落地，百果园须要无效的本地咨询服务与技术支持，否则只能自行摸索，耗时耗力。 “三步走”策略，CODING 助力百果园打造一体化研发管理体系百果园心愿将扩散在各工具的已有数据迁徙至一站式的研发管理工具，在企业外部打造对立的办公与合作平台，以满足数字化新零售业态下多我的项目、多零碎的研发治理需要。通过多轮技术评估与交换沟通，百果园最终抉择 CODING DevOps 作为对立的研发治理平台。百果园抉择 CODING DevOps 的起因在于： 灵便的我的项目事项及工作流配置：与业界支流的我的项目协同产品（如 Jira）对标，提供丰盛的事项类型、属性及状态配置，并反对定制实用于团队的工作流。这也使得百果园能在 CODING DevOps 平台沿用已有的我的项目合作形式，无需额定调整。弱小的一站式研发治理能力：提供从需要到设计、开发、构建、测试、公布到部署的全流程协同及研发工具撑持，实现一站式研发流程治理。业余的技术支持：提供 7x24 小时在线技术咨询和业余的培训服务，由专门的研发团队实现定制化开发。针对百果园工具切换所需的无缝数据迁徙服务以及迁徙之后的自研零碎对接问题，CODING 技术团队提供全面反对。 为了顺利合作百果园迈向一体化 DevOps 体系建设，CODING 采取了“三步走”策略，分阶段逐渐施行了解决方案。 第一步：梳理业务流程，定制团队合作工作流因为须要沿用已有的我的项目合作流程与模式，CODING 的技术支持团队首先梳理了百果园的需要流转过程。CODING DevOps 整合了百果园从需要评审、产品设计、开发、测试到公布验证全流程，确保各性能团队能围绕着产品需要发展更通明、更麻利的合作流动。 在 CODING 的帮忙下，百果园在 CODING DevOps 平台确定了「需要」在我的项目内流转的工作流。以产品需要为例，需要布局部门注销需要之后，会进入评审环节。需要评审通过之后，产品团队即可进行产品设计。若产品设计及 UI 设计方案通过评审，产品经理会针对相干我的项目人员进行产品宣讲。开发人员对需要明确无误之后，即可开始编写代码；而测试人员可在研发晚期阶段筹备测试用例，待开发实现编码之后进行测试，确保产品可稳固公布上线。 ...

本文为 CODING 高级产品经理王海明 在腾讯云 CIF 工程效力峰会上所做的分享。文末可返回峰会官网，观看回放并下载 PPT。大家好，我是 CODING 高级产品经理王海明，明天与大家分享的是我的项目协同 2.0 的设计理念及利用场景。 研发团队现状在所有上云的数字化时代，将诞生越来越多的软件公司和数字科技企业，传统研发治理形式和理念不能满足这些企业的倒退须要。 他们经常面临以下三个问题： 1. 产研矛盾 导致这一矛盾的起因，一是因为工具分治导致信息割裂，开发与需要脱节，产品不合乎预期；二是因为产品研发周期过长，无法控制危险；同时因为需要变动快，研发交付速度慢，因而无奈满足产品迅速迭代的要求。 2. 治理窘境 因为不同产品线研发流程不同，团队难以对立管控；而且管理者短少度量工具和治理视图，往往无奈无效利用研发资源；同时产品交付速度和品质无奈满足企业的倒退布局，导致交付产品与企业策略不匹配。 3. 理念悖论 因为新工具门槛高、与现有工具差别大、上下游工具无奈联动等起因，导致团队没有配套的实际工具，无奈实际瀑布或麻利等研发实践；同时因为无奈无效实际研发实践，往往呈现打着麻利的旗号理论在实际瀑布模式的景象，研发治理方法论与实际重大脱节；而且个别研发管理工具所撑持理念较繁多，仅有麻利或仅有传统瀑布模式都不能满足多研发模式并存的团队。 针对以上问题，CODING 推出了我的项目协同 2.0，是更适宜研发团队的项目管理工具。CODING 作为研发团队的基础设施，提供了从麻利治理到 DevOps 上线的一站式研发治理解决方案。我的项目协同作为所有需要的源头，笼罩了产品构想、打算到开发的残缺流程，迭代布局、需要合成、状态流转、看板视图、进度跟踪等能力一应俱全，让团队高效协同，进步交付效率。 我的项目协同设计理念上面我来为大家介绍一下 CODING 我的项目协同 2.0 的一些设计理念。我的项目协同的外围元素是事项和迭代，围绕二者造成了多种利用场景和配置计划。例如在麻利模式下是应用 Backlog 保护需要池、布局迭代、应用看板流转用户故事、查看燃尽图；在瀑布模式下，是通过打算页合成工作、分配任务、排期、注销工时等。从集体在工作台中实现集体工作，到我的项目成员在我的项目集中实现跨我的项目指标，我的项目协同对于产品研发的每个环节都做了场景化反对。 围绕价值流转和研发效力晋升，我的项目协同提供了以下几大性能与特色： 多种合作形式麻利工作模式 该模式是基于 Scrum 的麻利项目管理模式，从需要池开始到迭代布局再到看板流转，让开发过程颠三倒四，实用于定期迭代并交付价值的团队。瀑布开发模式 瀑布开发模式次要用于治理开发计划、合成需要和工作，能够让我的项目严格按计划流程推动，无效管制项目风险，实用于基于工夫或基于交付的软件我的项目。多我的项目协同模式——我的项目集 以上两种典型开发模式可在单我的项目中充分发挥劣势，然而一旦呈现一个产品线波及多个我的项目合作，就须要引入新的合作机制，这就是：我的项目集。 在我的项目协同中，咱们将我的项目集定义为：一组相关联且被协调治理的我的项目流动，以便取得别离管理所无奈取得的效益。我的项目集蕴含以下根本能力： 1. 我的项目集打算：录入我的项目集待办事项，合成事项并将各事项纳入计划中，并设立里程碑用以追踪要害事件停顿； 2. 合成打算到我的项目：我的项目集波及多我的项目合作，可将我的项目集内事项合成到我的项目中去实现； 3. 风险管理：在合作中辨认危险及时上报，并在我的项目集中对危险进行集中管理、追踪和解决。 自定义合作模式 在自定义合作模式下，不同事项类型的组合造成不同的合作模式，从而能够解锁更多的我的项目合作模式，使得团队在 CODING 中不必局限于以上两种根底合作模式。弱小的自定义引擎事项类型的自定义能力得益于 CODING 弱小的自定义引擎。可为团队打造独有的事项类型，并定制与之匹配的开发流程： 自定义事项属性 事项的属性是内容的次要承载体，CODING 的事项属性反对自定义，提供了丰盛的数据类型以供选择，涵盖文本、数字、单选菜单、多选菜单等根底数据类型，和成员抉择、迭代抉择等我的项目内数据源。自定义事项工作流 流程是信息有序流转的外围，CODING 的事项工作流可自定义，不仅提供了状态定义、流程自定义，还反对多种步骤流转规定，例如：步骤权限、附加属性、主动更改解决人、主动更改属性等。 丰盛的多视角合作不同的团队有不同的工作流程，不同的角色有不同的工作视角。每个角色在不同合作状况下的聚焦点不同，为此 CODING 提供了丰盛多样的合作视角和视图模式： 工作台：让成员聚焦于集体未实现的工作；筛选器：将简单的事项的筛选条件保留下来，以供随时检索，并可设为我的项目共享筛选器；丰盛的事项列表视图：事项反对平铺、树状、看板、甘特图，并且自定义表头；Backlog 页面：产品负责人（Product Owner）解决用户故事的次要界面，随时对用户故事进行排序并布局进迭代；迭代看板：麻利团队在迭代过程中的次要合作界面，用户故事的流转高深莫测。看板反对自定义，为麻利团队提供了更丰盛的合作模式。 数据互通与集成CODING 作为一站式开发合作工具， 提供了丰盛的工具模块，从合作、治理到编码开发再到常识积淀，实现了云上研发工作流的全面笼罩。我的项目协同作为合作的中枢神经，承载的内容不止是简略的需要或工作，还能够将其余模块互通，例如：指标治理能够关联到我的项目内工作，与公司战略目标联动；测试治理中的测试计划、测试用例能够与迭代、需要、缺点等进行关联；代码仓库、合并申请等代码资源能够关联需要和工作；常识和文档也可能关联到需要和工作中，充分利用团队的常识积淀。 ...

本文为 CODING 协同产品总监张路宇 在腾讯云 CIF 工程效力峰会上所做的分享。文末可返回峰会官网，观看回放并下载 PPT。欢送各位朋友，来到腾讯云 CIF 工程效力峰会的分论坛，我是 CODING 的产品经理路宇，很快乐能以这种形式与大家见面。在接下来的主题环节中，会由我先为大家带来 CODING DevOps 研发平台的产品理念和全景解读，咱们还邀请了几位往年下半年的新产品负责人给大家带来对于我的项目协同、WePack、以及全新产品继续部署 Oribt 和研发流程治理 Compass 的分享（讲稿已在陆续收回）。 我退出 CODING 曾经三年了，此前有近十年的研发治理经验，我同时是一个不折不扣的效率工具爱好者。过来几年里我看到了外乡研发团队、业界，以及 CODING 产品对研发工具理念了解的三个阶段性变动：从工具、到工具箱、再到软件工厂。 工具、工具箱到软件工厂东方经典治理实践认为，组织效率能够归为劳动效率、组织效率和人的效率。美国管理学家泰勒所著的《科学管理原理》被德鲁克誉为“20世纪最平凡的创造”，劳动效率说认为分工晋升生产效率，福特的流水线就是分工和工业化的典型代表。经济学家亚当斯密在《国富论》形容了螺丝制作的十八道工序，别离由十八个专门的工人负责实现。以马克思·韦伯为代表的组织理论家认为，无效的划分岗位，造成官僚组织构造可能开释效率，正当、非法的权力是促成组织达到本身指标的必要条件。组织效率最大化的伎俩是专业化程度与等级制度的联合。用咱们明天的话说，就是让不同业余能力的人匹配适宜的岗位。玛丽·芙丽特则提出了「以人为本」的人力资源管理实践，更加关注人的心理，治理中须要均衡员工需要与组织倒退的指标。 古代数字化、平台化企业强调翻新和协同，在经典治理实践的根底上又提出了新的挑战，仅仅分工曾经不能满足市场的须要，咱们发现： 1.强个体的价值崛起，最有价值的翻新是由企业内少部分人实现的； 2.影响组织绩效的因素由外部转向内部，所有员工都须要关注交付内容的价值和客户须要。效力 = 价值 X 效率。如果价值为 0，再高的效率也于事无补； 3.因为需要多样化和疾速变动，驾驭不确定性成为组织的外围挑战。不确定性是一把双刃剑，可能把握不确定性便是专一了企业倒退的机会。 以上，是咱们认为的数字化协同的实践根基，治理逻辑正在从分工走向协同，好的工具须要遵循经典的分工实践，但更加须要重视数字经济时代的协同需要。 咱们提出这样一个问题 —— 软件研发还是数字化协同的领军行业吗？我找了这样一张 DevOps 2021 年的生态地图，如下图所示，像这样的图片想必大家近年来看到了许多。围绕代码的构建、测试、部署、运行环境、监控、项目管理以及信息流等等的工具层出不穷，这反映了咱们所处的技术环境正在疾速变动，软件从业人员确实越来越长于应用工具。 你的团队可能在用 Jira 进行项目管理，用 Gitlab 治理代码，用 Jenkins 实现继续集成，用 JFrog 治理制品……然而，一个研发团队须要应用如此多的工具，作为技术决策者在抉择时面临不少的压力。从学习、部署再到利用，老本经不起计算。一位新共事入职，须要开上七八个账号，数字资产的治理面临潜在危险。 更重要的是，咱们认为在这种工具集状态下，没有给开发者和管理者提供一个真正无效、柔性边界协同的环境。 显然，相比一些高集成度的数字化行业，甚至传统行业，咱们不能自信的说咱们正放弃当先。技术决策者们刚刚走出工具时代，正停留在工具箱时代，迫切的须要一个新形态的协同环境迎接挑战。因而，CODING 提出了数字化软件工厂的概念。这也恰好合乎 CODING 产品的演进路线。 2014 年，CODING 率先推出基于 Git 的代码托管服务工具，成为国内当先的代码托管服务平台，也是在此时提出了「云端开发，让开发更简略」的理念。2018 年，咱们推出我的项目协同、继续集成、Cloud Studio 等产品，造成了一系列的必备研发工具，这些工具通过工夫的打磨曾经达到了国内较领先水平。去年，CODING 首批取得了信通院 DevOps “卓越级”认证，这也是国内最高级别的 DevOps 工具体系认证。往年，咱们提出策略降级，联合古代软件工程实际和先进理念，推出研发度量、研发流程治理 Compass 等产品，打造有凋谢生态能力的数字化软件研发工作流。 ...

本文依据 CODING Compass 产品总监程胜聪在腾讯云 CIF 工程效力峰会上所做的分享，进行了整顿与更新。文末可返回峰会官网，观看回放并下载 PPT。DevOps 从工具化阶段迈入流程化阶段软件工程从上世纪 60 年代倒退到当初，毫无疑问正处于 DevOps 的时代，这几年业内热火朝天的 DevOps 转型也印证了这一点。到当初这个阶段，企业在转型落地上也继续投入了这么多年，开始迫切希望看到成绩。大家广泛在思考一个问题，那就是 DevOps 是否真的对业务倒退和数字化转型带来帮忙，还是只是研发团队自嗨而已？ 在最近一年帮助客户进行 DevOps 产品落地的过程中，咱们愈发意识到：研发治理真的不能只靠搭建工具链，还须要把这些工具利用到企业理论的业务流程当中。 咱们应该切实的为开发减负，而不是反而给业务的开发减少累赘。只有这样才可能切实晋升研发效力，更好地满足业务倒退的须要。 如果说，DevOps 在之前还属于工具化阶段，各式各样的工具层出不穷，那么在数字业务倒退迅猛的背景下，DevOps 正在进入一个新的阶段：流程化阶段。 企业应用 DevOps 工具依然存在挑战先从一个典型的用户反馈登程，来看看以后用户所处的窘境： 下面这个客户深刻应用 CODING 一年多，他们对产品是否好用有足够的话语权。通过对反馈后果的整顿，能够看出工具化阶段的产品还是存在有余。一方面，客户充分肯定了当初抉择 CODING DevOps 的决定，团队中每个角色都可能在一站式平台上工作，很好地实现了研发一体化的指标；另一方面，只管咱们的一站式平台提供了团队所需的能力模块，然而不同模块之间的协作性还不能很好体现。 对产品来说，其关注的需要流动并不能很好关联到开发理论在做的事件，从而对停顿和危险不能齐全掌控。对于开发来说，更新工作状态是很重要，然而因为这个事件并不会阻塞本人，是否及时更新就齐全取决于自觉性高下。于是很多时候，忙于合作编程的开发往往会遗记去做这个事件。同时，作为绝对后置的测试，一旦提测，各种事项查看更是茫茫多，各种信息核查和更新就要破费大量的工夫，加上留给测试的工夫原本就不多，状况就显得特地困顿。而再前面的运维共事更不用说了，只能重复叮咛发版之前要做好充分准备，各种验证查看都不能打折扣，而后就只能祷告别总是在敏感的公布窗口，呈现各种莫名其妙的问题。总的来说，尽管在一个平台上的不同工具大家都用得很顺畅，但从全流程来看总感觉短少点什么。在工具之间的来回切换依然须要破费大量精力，而且还不能确保信息的正确性。种种这些，都是工具型产品的不足之处。 企业日渐关注研发治理的整体效率这个案例并非个案，而是 DevOps 转型来到了新的流程化阶段的标记：企业日渐关注研发治理的整体效率，从强调某个工具的局部优化，转变为强调协同流程的全局优化。 工具并不能等同于整体效率，组织效力治理的经典实践 PPT 中就指出：一个组织的 3 个因素中，People、人是根底，Tools、工具对人进行赋能，让工作更有效率，而 Process、流程则是让人的行为与指标保持一致的载体。完满地实现一件原本就不应该去做的事件是毫无意义的，甚至还会对整体造成侵害。从全局上思考，一个好的流程不可或缺。 DevOps 产品应该打造成为进一步解放生产力的新型生产关系在数字化的背景下，业务迅猛发展带来了软件系统的高复杂度，个体须要解决的事件变得更多，导致单人效率降落。为了晋升团队中每个角色的工作效率，企业谋求 DevOps 转型，心愿利用新兴技术和工具来迅速进步团队生产力。然而随着在技术和工具上投入越多，以及团队规模不断扩大，同时也带来了整体合作上的复杂度。而这些简单的依赖关系如同金字塔般层层传导至团队成员身上，造成了对原有工作习惯乃至了解认知的微小冲击。哪怕是一次简略的交付，都须要通过许多操作以及不同角色的协同，整个交付过程也因而显得软弱和低效：比方工作上下游的契约和标准缺失，研发过程的透明度不够，须要在不同工具平台之间来回切换等等。 如何能力让不同的工具，有机地共存于一个残缺的流程当中呢？如何为团队打造高效的流程，让人可能顺畅地实现高质量的软件开发，并公布到生产环境中？在这个过程中，团队成员不须要去解决不必要的简单问题，陷入细枝末节之中，又或者是长时间的期待延误。咱们应该解放团队成员的生产力，让开发能把精力集中在能真正产生业务价值的工作上。这是以后很值得思考的事件：就像生产力决定生产关系一样，咱们须要更先进的研发治理产品来赋能研发团队，来满足现今数字化业务倒退的需要。 CODING Compass：DevOps 流程化阶段的研发流程治理产品通过对 DevOps 实际落地中凸显进去的问题的梳理，咱们得出了以下 2 个方面的意识： 1. 组织层面的 DevOps 转型须要领域专家 7 月份信通院公布的《中国 DevOps 现状调查报告（2021）》中就指出：靠近 30% 的企业因为短少 DevOps 专家导致推动落地迟缓。而在咱们服务客户的时候，也往往须要提供征询，通过专家诊断、制订流程，而后依据理论状况、设定要晋升的指标以及具体的实现门路。DevOps 产品要做的是：提炼出业内卓有成效的研发治理教训、并内嵌到产品当中，疏导客户团队把优良的习惯固化下来、继续优化，从而实现高效的研发治理。 ...

直播来啦！本次云原生学院邀请到腾讯云 CODING DevOps 后端工程师王炜为大家分享《开源的云原生开发环境 —— Nocalhost》。 直播信息讲师：王炜 - 腾讯云 CODING DevOps 后端工程师工夫：1 月 14 日（周四）晚 20:00 - 21:00直播间：https://live.bilibili.com/222...发问地址：https://docs.qq.com/doc/DR1Rt...也可扫描下方二维码向导师发问 分享纲要1.Nocalhost 因何而生 2.Kubernetes 环境下支流的开发方式 3.Nocalhost 的愿景 4.Nocalhost 的实现原理、个性和组件 5.应用 Nocalhost 来开发 Bookinfo 用户播种理解如何应用 Nocalhost 进步云原生环境下的开发效率，缩短开发反馈循环。 直播福利福利：观看直播参加互动，就有机会取得电子工业出版社资助的《Kubernetes 网络权威指南》 全书内容并不局限于 Kubernetes。作者对本书的定位是云原生畛域的网络权威指南，企业落地计划的选型参考。本书特地重视提供了解容器网络所必须的基础知识，会由浅入深地从架构、应用、实现原理等多方面开展，试图为读者出现整个云原生网络的常识体系。全书的脉络是：以 Linux 网络虚拟化根底作为“暖场嘉宾”，以 Docker 原生的容器网络“承前启后”，随后是配角 Kubernetes 网络“弹冠相庆”，在各类 CNI 插件“疆场点兵”过后，以代表容器下半场的服务网格 Istio“谢幕”。 关注直播间，课程不错过！

12 月 22 日，SegmentFault 思否·中国技术先锋年度评比榜单公布，腾讯云 CODING 凭借在 DevOps 畛域当先的产品能力和业余的服务，荣获【中国技术品牌影响力企业】奖项。 SegmentFault 思否作为中国当先的新一代开发者社区，依靠数百万开发者用户数据分析，及各科技企业和集体在国内技术畛域的行为、影响力指标，深度考查入围企业，最终评比出 30 家上榜企业，和「生态倒退奖」、「中国技术品牌营销奖」、「技术向善奖」、「技术文化奖」、「最佳技术服务奖」五大奖项。 CODING DevOps 作为腾讯云旗下一站式研发治理合作平台，提供了代码托管、项目管理、继续集成、测试治理、继续部署、制品治理和 Wiki 知识库等性能服务，涵盖了软件开发从构想到交付的所有所需。始终以来，腾讯云 CODING 都在继续推动开发者生态的建设，以最近新公布的产品——云原生开发环境 Nocalhost 为例，CODING 将 Nocalhost 全副源码开源至 Github，同时恪守 Apache 协定并放弃厂商中立，拥抱社区文化，激励所有开发者独特参加 CODING 产品乃至云原生畛域的提高和成长。在将来的几年里，CODING 将持续致力于为国内企业及集体开发者提供更加全面的 DevOps 平台，推动企业数字化转型的步调。2021 年，咱们将继续加强生态建设，服务更多的开发者，和开发者独特成长。 点击立刻体验一站式 DevOps 服务

原文地址： https://medium.com/startup-pa... 翻译君：敏杰小王子上周，我站在一家市值 200 亿美元的公司的会议室里，推动了一个关于敏捷的研讨会。出席会议的小组由这家大公司的一个产品线中的每个职能部门的董事和部门经理组成。从 UX、工程和产品管理的岗位中挑选出来的十几位领导者组成了一支团队，他们代表着约 150 人的产品线。作为一个团队，他们踏上了“敏捷”的旅程。 这不是我们平时认为的企业转型。他们的高层既没有明确支持也没有明确阻挠这次转型，这家公司对敏捷的官方态度最准确的描述是“良性冷漠”。因此，这个团队基本上只能靠自己来尝试，无论最终结果是成功还是失败。 我在那里的唯一原因，是因为到目前为止敏捷旅程还不顺利，我的任务是帮助他们找出症结并解决它。好巧不巧，他们出现的问题与我在过去 5 年中遇到其他团队的原因相同。为简单起见，以下都是直言不讳的事实陈述，但也并非都适用于您的情况。 不明确的愿景如果你在办公室走廊拦住任何团队成员，问他：“同学，我们产品的长期愿景是什么？”他们能否用一两句话来回答？八成不行。他们可能对目标客户有所了解，也可以明确地知道解决方案的功能。但是，他们真的可以说出客户想要解决的痛点吗？我猜不会。 一些高级管理人员在权利更迭期间，以临别顿悟为基础传达了自己的“突发奇想”。这个“想法”被投入了预算计划角逐会议中，这位特别的高管最终赢得了影响力战，并得到了 12 个月的项目资助。紧接着这一消息的所有内容通过一个既成事实的 PPT 传递给你，功能和时间表提前计划好了，你被正式告知“请实现它”。现在你正试图完成那个不可能完成的任务，并希望敏捷能帮到你。 解决方案：花一些时间阐明产品的清晰愿景，使用业务模型或精简图片表达您的设想，邀请团队中的每个人参与，将这些设想反馈给高层管理人员（如果他们拒绝参加），并确保你的相关信息出现在同一页面上。 PS：如果他们找你麻烦，给我打个电话。 被混淆的业务指标该团队不会考虑日常的成本和收入。事实上，团队可能不知道公司要让他们赚多少钱，他们也不知道他们需要拓展多少客户，每个时间段需要支付多少钱，以便他们在这个疯狂的想法上实现收支平衡。他们基本上不太关心自己的工资来自何处。 但如果你问大多数初创公司，他们对自己整体燃烧率和销售业绩会有更好的了解，因为收入和盈利能力对于他们来说始终是最重要的。 其实这个成本在任何情况下都不难计算。直线经理（Line Manager）通常可以在几分钟内得出工程团队燃烧率的准确数字。然后当我们将这个数字（实际成本）与我们当前的销售数据（我们作为一个团队实际产生的收入）进行比较时，这就会是一个全新的业务竞赛。 译者注：直线经理（Line Manager）是指诸如财务、生产、销售等职能部门经理，每一个直线经理肩负着完成部门目标和对部门进行管理的职责。 解决方案：计算您的产品成功所需的团队收入和成本，并确保每个人都知晓。它很有可能会让人大开眼界。您应该在下一次业务规划会议上与您的团队一起尝试。 持续不断的干涉由于方向上的某些紧急变化，您最后一次中断正常工作流是什么时候？它可以是最近的客户投诉或请求，也可以是来自首席执行官措辞强烈的电子邮件——邮件涉及团队在上周产品演示中使用的配色方案。 无论如何，如果你总是打破团队的正常工作流，会给团队带来巨大的压力。这种压力转化为吞吐量降低、士气低落、人员流动率增加、航运延误、工艺粗劣、以及对团队绩效的普遍拖累。所以把这个坏习惯丢弃掉吧，您并没有因为在组织中的管理地位而拥有在事务优先级排序方案中的特权。 解决方案：每周为计划外工作分配一些容量，比如总容量的 20％，只安排 80％ 的团队时间，而不计划其余的时间。可以在发生“紧急情况”时使用此容量，而不会影响原来的正常计划。无人认领的话可以用它来偿还技术债务。您可以轮换团队成员来执行此操作。 不够专注的团队我工作过的每个大公司都有这个问题。项目中的大多数人被分配到多个其他项目当中。当我问团队中都有谁时，我得到的答案一般是某位工程师分配了 50％ 在这个项目上，而某位工程师与我们在一起的时间占 20％，超过一半的项目人员将一半以上的时间花在其他项目上。难怪项目的最终结果往往是事故，因为这种工作方式不管用。 产品开发是一项团队活动，团队成员之间需要极大的关注和大量的沟通和协调。您团队中的每个人在部分时间内被分配到其他项目，这会使交付日期常常延迟数周或数月。 关于这一点我从企业管理者那里得到了更多的案例，举一个具体的例子，你也许会问：“我们真的需要在团队中设置专门的产品体验人员吗？如果他们一半闲着怎么办？我们不是在浪费钱吗？” 让我们思考一下： 假设你有十个工程师和一个交互设计师（本来不应该是这个 1/10 的比例，但你可能会这样做，所以我们姑且先这么选着）。设计师为工程师构建了 100 个线框，现在你有 10 名工程师开始工作，设计师又回到了其他项目。工程师几乎立即向设计师提出了要求，但设计师此时被其他项目束缚，所以工程师必须等待（延迟）。也许工程师选择打开另一项任务并开始工作。当设计师重新上线时，工程师必须暂时放下第二个任务以重新打开第一个任务（延迟）。 现在，第二位工程师需要帮助，可能还有第三个工程师，他们都在等待（延迟）。设计师再次有空并开始与第一位工程师合作，而其他两位排队等候（延迟），后两者的任务未完成（延迟）。所有三位工程师都失去了他们正在研究的一些事情的背景（延迟）。 在与第一位工程师合作时，设计师发现了设计中的错误，需要更新所有 100 个线框（大延迟）。现在，每个工程师都必须停止并重新检查他们的工作以应对新设计（大延迟），已经完成的一些工作必须废弃并重新开始（更大的延迟）。 所以你是选择固执己见还是有所改变？您可以试试把上面的示例中替换成后端 API 开发人员，事情的结果会变得更糟。 解决方案：请组织小型、跨职能、专注的团队，将一小组作为一个单元一起工作，并不断获得双方关于事务进展的反馈与澄清。 分散各地的团队大型企业团队往往由一个地理位置分散的大型池的“资源”组成（原谅我用“资源”这个词）。因此，企业产品团队的成员处于不同的时区和地区，这使得沟通协调效率低下且成本昂贵，结果就会发生很多延迟等待和错误传达。远程通信的保真度绝对不如面对面沟通，视频通话确实让沟通变得更容易一些，但它与能够一起走到白板前讨论出来的东西并不相同。 解决方案：将所有团队成员放在同一个房间，或至少在同一建筑物的同一楼层。如果您必须与远程人员一起工作，请根据康威定律分解任务，按地理划分（具有明确定义的接口的模块）而不是按功能划分（设计、工程）。 太过臃肿的团队通常情况下，在企业中找到大型团队来构建产品不是那么复杂的事情。但由于各种原因，团队规模常常大得惊人，这主要与高管倾向于通过指挥大群人来建立自我的事实有关。 100 名工程师构建一个 SaaS 产品？你确定？较大的团队效率更慢，因为协调成本是巨大的。您需要更多层次的管理，更多会议和更多文档。大型团队对其速度的负面影响随着其增长而渐渐变得更强烈。 解决方案：您应该使用尽可能小的团队在企业中构建产品。如果你可以把它减少到几十个，甚至一打，那就更好。 太重的技术债务企业往往有很多旧的代码库。然而这并不是企业敏捷团队积累技术债务的真正原因。我敢打赌，您当前项目中的大部分技术债务是从您当前项目开始以来由您的团队创建的，而不是通过来自较旧的遗留系统的继承。 这是因为，尽管敏捷社区重复了 15 年： （1）结对编程技术实践的重要性 （2）测试驱动开发 （3）对代码的持续集成但非常少的企业团队真正去做这些事情。出于各种原因（主要是因为那些专注于流程而非卓越技术的大型咨询公司向高管出售的所谓“敏捷”），企业敏捷团队很少接受：核心技术实践使得敏捷出色。结果大型的工程团队开始设计和执行有缺陷的系统，然后在漫长而痛苦的发布周期中相互折磨。 ...

近期 CODING 团队在 2019 KubeCon 大会上发布 DevOps 一站式解决方案：CODING 2.0。此次 CODING 全新上线了持续集成与制品库模块，通过自动化与标准化的方式来帮助开发者摆脱编译、构建、集成、制品管理等重复劳动，旨在打造沉浸式开发体验。在 KubeCon 大会现场，我们以一个基于 Spring 的模版项目为例，展示了开发者如何基于 CODING 轻松完成编码到构建制品的过程。 新项目创建首先新建一个项目，选择一个您熟悉的开发语言预置模版。预置代码模版提供了从代码生成、持续集成、制品库的自动配置，并已预置了 Dockerfile ，实现 Docker 容器化的打包方式。目前代码模版已内置了包括 Java、Ruby、Android、Node.js、Python 等主流语言开发框架的网页或移动端应用。 只需几分钟，项目即可创建完毕。CODING 为您创建了一个代码仓库，并将一个简单 Java 网页应用的代码推送到仓库 master 分支，还为您创建一条可直接运行的构建流水线，产物为 Docker 镜像。基于创建好的代码仓库和构建流水线您可以立即进行代码开发，并且快速集成代码。 接下来我们基于创建好的模版项目 spring-demo ，通过三个环节：代码托管、持续集成、制品管理，来看看 CODING 的 DevOps 配置具体是什么样的。 代码托管CODING 提供代码托管能力，并支持 Git 与 SVN 的代码提交方式。在自动生成的代码仓库中我们看到了 Maven 编译脚本、Jenkins 构建脚本、Docker 镜像打包脚本、网页应用的源码。在 README 文件中详细介绍了各个源码文件的作用以及如何运行该网页应用，对于开发新手来说可以说是手把手程度的详细介绍。您可以通过本地 Git/SVN 客户端来提交代码。 持续集成修改后的代码如何集成到软件当中来？我们来看看预置模版下生成好的构建任务，并学习如何修改持续集成配置以满足更多的场景需求。 在下图中可以看到系统已自动运行过第一次的构建，在持续集成首页您可以清晰地看到每次构建结果的状态、触发原因、持续时长等基本信息。CODING 的持续集成支持多 Job 并发运行，如果您的研发团队有这方面的需求，在持续集成页面按需创建多个构建任务即可。 在构建记录中您可以看到每次构建结果的详细信息。比如构建过程的运行状态，如果遇到构建失败的情况，您就可以在该页面查看失败环节的日志信息以便快速修复构建流水线。您还可以看到改动记录、测试报告、还有生成的构建产物（比如 Jar/War/脚本/配置文件等构建半成品）。最终的构建产物（比如 Docker 镜像）通过简单配置即可自动推入制品库中，稍后我们会详细介绍制品库。 接下来我们来看看构建任务的具体配置是怎样的。在触发方式中您可以按需设置触发方式、邮件通知人员。在持续集成过程中您可以选择通过图形化编辑器或者文本编辑器（如果您对 Jenkinsfile 脚本熟悉）的方式来详细配置构建的每个环节。针对一些持续集成过程中无法明文展示或者易变的信息，您可以通过环境变量或者凭据注入的方式来进行设置。如果想要加快构建速度，您可以打开缓存配置，同时还支持清空重置。 ...

在文章开始前，做一个小调查，在您的软件项目中集成一行新代码平均需要花多长时间？ 15 分钟一小时半天一天及以上注意这里的集成是指将源码放在一起，并验证源码可以作为一个一致、运行可靠的软件的过程，而不只是完成编译。 如果在软件集成阶段耗费的时间经常让您的研发团队加班加点，那么是时候考虑落地持续集成了。我们都知道软件只有从代码生成制品，最终部署到生产环境中可靠运行才会给公司带来收入。持续集成是一种以“反馈”为核心的实践，为了达到短周期、高质量的交付目标，研发团队需要频繁且自动化地发布软件。每次修改代码都进行集成可以让上线的时间尽可能短，开发人员也可尽早发现缺陷以便快速修复。 拥抱自动化，打造沉浸式开发体验CODING 持续集成（CCI）全面兼容 Jenkins 的持续集成服务，支持 Java、Python、Node.js 等所有主流语言编译环境，并且支持 Docker 镜像的构建。只要几步配置，就可以开启 Git 代码仓库的持续集成，包括 CODING 代码托管、GitHub、GitLab 等等。帮助您控制每一次从引入代码变更到发布的整个过程，从而更好地优化软件交付的速度和质量。 人力资源是非常有价值的，所以研发团队应该把人力放在开发新功能上，而不是那些枯燥且易出错的重复劳动上，比如像编译、打包、质量检查这类工作可以考虑都由 CODING 的持续集成来完成。 即使项目规模不大，我们也相信研发组织能从 CODING 的持续集成中受益。因为小项目会逐步成长为大项目，一开始就使用规范、自动化的方式进行软件集成，可以减少团队更替或者新人加入带来的沟通成本；尽早卸掉流程债务与管理债务，可以避免项目庞大失控后陷入交付沼泽中无法上岸。 深度优化，助力企业加速落地持续集成CODING 的持续集成在构建效率、使用门槛、构建物管理等方面都进行了深度优化。包括支持图形化编排以提高开箱即用的体验；高配集群多 Job 并行构建提速您的构建任务；统一的构建产物管理真正打通持续集成与持续交付的枢纽；凭据注入让持续集成更加安全易用。接下来我们来具体看看这些优化： 更友好的新手体验：图形化编排可视化的图形编排对于用户快速直观地理解、编排工作流水线是非常必要的。CODING 在基于编辑 Jenkinsfile 的核心功能之上设计了可视化视图，针对构建的每一个步骤提供丰富的构建脚本模板供用户选择。同时也兼容绝大部分自定义操作，实现了边写边看、所见即所得的直观编辑体验，降低了 Jenkinsfile 新手的使用门槛。 更快速的构建效率：多 Job 并行与缓存加速CODING 支持在一个项目当中并行构建多个 Job，以满足重度持续集成用户的需求。后端的服务器集群可以根据用户的需求实施调度响应的计算资源，保证用户的构建任务快速开始，减少排队时间；同时支持在不同的构建任务之间开启缓存，以提高反复构建的速度。开启缓存功能可以平均提高 300% 的构建速度。 更完整的构建流程：制品库管理CODING 制品库支持 Docker Image、Maven/Jar、Kubernetes Helm、Node.js NPM 包等常见软件包类型。制品库可以跟源代码协同进行版本化控制，可以与本地各构建工具和云上的持续集成、持续部署无缝结合，帮助您以标准化的方式管理构建产物。 更安全的鉴权机制：凭据注入在持续集成之后需要将构建产物自动存入制品库当中。不放心将制品库的账号密码配置在脚本或者是环境变量当中？CODING 提供了更为安全便捷的凭据注入方式，开发者通过服务连接的方式新建连接，配置好连接 ID 即可将持续集成产物推送到制品库中。 持续集成让开发者甩掉软件集成过程中的重复劳动并提高了代码质量。在这样的安全环境中，开发者更敢于创新，尝试新的想法。对于专业的软件研发组织来讲，版本控制、敏捷开发、持续集成等等都是非常重要的研发实践。CODING 通过日益完善的 DevOps 工具链，将前沿研发理念注入其中，帮助企业研发组织提高研发效率，让开发更简单。 点击下方，了解更多 CODING 2.0 升级资讯： 《CODING 2.0 企业级持续交付解决方案》 《CODING 2.0：为什么我们需要 DevOps》 《CODING 2.0 服务升级：一站式服务体系助力企业研发上云》 《CODING 2.0：如何通过设计给品牌创造价值？》 《打通 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 理念的全面升级，CODING 正构建起覆盖构想到交付的全覆盖工具链，用户注册即可实践敏捷开发与 DevOps，提升软件交付质量与速度。 一直以来，CODING 作为软件研发领域的开拓者，代码托管、Cloud Studio、Pages 等作为极客代表的明星产品，使得 CODING 的品牌气质一直给人一种创新、前卫的印象。我们在新版官网的设计上仍然延续 “极客” 的概念。但同时，作为一个面向企业的产品，CODING 也需要展现出严谨可靠的一面。 官网是客户对产品的第一印象，很多潜在客户第一次对 CODING 产生认知就是发生在 CODING 的首页。在这样的背景下，CODING 官网需要进行一次全面的升级。 设计挑战市面上企业级产品的官网设计大多以严肃、板正的形象为主。如何追求创新，在设计上寻求自身的核心竞争力；如何正确的传递信息，将官网设计好看的同时又能促进转化，给品牌带来价值，是本次官网设计改版最大的挑战。 如何设计好看又能创造品牌价值的官网？CODING 的官网主要由首页、产品详情页、价格、支持四个部分组成，这里重点介绍官网首页的设计理念。首页展示的内容信息就好比在给用户讲述一个产品故事，如何让用户记住这个故事，光有一个好的文案是不够的，更需要通过优秀的设计传达。 1、大胆的首屏设计抓住用户视角 首屏是官网最核心的位置，如何在首屏抓住用户视角至关重要。配图部分我们仍然延续 2.5D 等宽插画的风格。小人点亮屏幕操作一行代码后，机器被发动开启一站式 DevOps ，这一过程的动效十分契合 CODING 的产品价值主张。 我们尝试过两种首屏排版方案，一种通栏式，一种异形式。但由于通栏式的单一铺底排版让首页气质看起来非常保守，不符合极客的品牌定位。为了追求创新，我们最终选择了大胆的异形式排版方案。 2、流程化的功能介绍引导用户阅览 功能介绍是首页最为重要的部分，这个部分能引导用户初步了解公司产品功能，设计上需要给用户营造良好的阅读体验。软件研发从构思->计划->开发->测试->交付整个流程，我们采用步骤式交互引导，带领用户一步一步浏览完整的功能介绍。另外每一个模块都使用真实的配图让用户有亲自操作 CODING 功能界面的感觉。 我们在设计上舍弃之前使用的背景色块分割区域手法，采用了开放式的布局形式，让这些散落的功能点描述看起来是一个整体功能的介绍内容。背景图案提炼出对应功能图标的元素用来点缀，让排版显得更加生动活泼。 3、知名企业的客户案例增强用户信任感 这个模块里我们将客户故事和客户 logo 墙一起展示，通过阅读大客户的案例故事，把用户带入不同行业的使用场景中去。企业客户在选择产品的时候看到与自己行业匹配的大企业也选择该产品，有助于提升好感度和信任度。 4、完善的产品详情页促进用户深入了解产品 产品详情页通过简介、特性、使用场景让用户能更深入地了解产品，页面风格选择比较中性的排版形式。值得一提的是我们为 CODING 的产品功能设计了一组抽象的概念图标，图标的元素同时也用作首屏背景。这种强烈的映射关系能够更好的统一整个介绍页的风格。 总结CODING 官网正式上线以来，经过近两个月的观察，官网跳出率比之前降低了 20%，充分证明这次升级给官网带来了价值。总结一下，提升企业级官网体验需要具备四个基本要素：吸引用户眼球的首屏刺激访问；条理清晰的功能介绍引导阅览；知名企业的客户案例增强信任；完善的产品详情页促进转化。 以上是我们团队对这次改版的总结，希望能够给设计师朋友们提供一些参考价值。首页欣赏： 点击下方，了解更多 CODING 2.0 升级资讯： 《CODING 2.0 企业级持续交付解决方案》 《CODING 2.0：为什么我们需要 DevOps》 《CODING 2.0 服务升级：一站式服务体系助力企业研发上云》 点击使用 CODING 2.0 体验 DevOps 全工具链敏捷研发

CODING 在前两天的 Kubecon 2019 大会上发布了 CODING 2.0。这背后是 CODING 对研发管理和研发团队组建的思考。从 CODING 成立以来，我们一直在探索“让开发更简单”的方式。把“让开发更简单”这个大愿景进行拆分，具体到可量化的产品目标上去，实际上是希望通过工具的形式，可以减轻开发过程中的重复劳动，提高软件交付的速度与质量。 云端开发的初心最开始做 CODING 的时候，脑海中的蓝图是开发者在这里讨论需求、布置任务、写代码，改代码，演示代码，完成相关任务，整套的开发操作都在这里。 所以当时的产品结构是：轻量级的任务管理 - 讨论 - 代码版本管理 - 演示平台在这套产品体系下，产品经理会把任务指派给设计师，设计师完成设计后，产品经理验收后再把任务指派给研发人员，研发人员推送代码后，可以在演示平台做演示给产品经理验收。这是一套非常适合小团队的工作模型，流程简单，反应快速，CODING 自己团队也在使用，并且支撑了 CODING 产品前期的快速起步，快速上线，快速响应反馈的开发节奏。 企业在成长过程中碰到的实际问题很快，随着 CODING 业务的发展，CODING 的产品线越来越多，团队也越来越大，当团队到达 100 人的时候（其中 60% 都是研发），我们发现团队开始"管不动"了，最终的上线质量非常依赖部门 Leader 的管理能力和开发者的自我修养。为了保证产品达到预期，我们制定了大量流程和规范，但这让我们的进度越变越慢了。我们一度非常苦恼，创业公司的优势在于极高的效率与极快的产品迭代，但如果我们在发展的过程中丢失了这样的优势，将会很轻易的被别人超过。 所幸我们并不是第一个碰到这个问题的人。《人月神话》中有个很著名的观点： Adding manpower to a late software project makes it later.-- Fred Brooks, (1975)“如果希望用增加人力的方式解决软件的进度问题，只会让进度变得更慢。”因为： 沟通成本= n(n-1)/2 n=团队人数举例而言 10 个人的团队将有 45 个沟通管道，当人数到达 50 人时，这个数字将上升为 1225 个。随着人数的增多，团队内的沟通成本将指数级上升。了解到问题出现的原因，也就知道了解决方案：“我们需要更多更小的团队”——通过将团队分成若干个内部闭环的小团队来降低沟通成本。于是我们有了一个稍微敏捷一点的组织架构： 这个工作方式敏捷的很不彻底，问题在于运维。考虑到线上稳定性及系统的耦合程度，无法将运维拆到各个团队中去，各个产品线虽然有独立的产品经理、设计师和开发者，但需要运维协助上线测试环境，再由测试进行 testing 和 staging 两个环境进行测试验收。大量的时间被无用的等待浪费掉了。 ...

"The key to DevOps transformation is that there is no end-state—we must continuously evolve." —— MIRCO HERING, DevOps 全球领袖 今日，CODING 受合作伙伴腾讯云邀请参加 KubeCon、CloudNativeCon 和 Open Source Summit 在上海举办的 KubeCon 2019 技术论坛，并于论坛上正式发布了专注于大型项目 DevOps 实践的产品：CODING 2.0。 会场照片 如今互联网行业已经进入了深水区，新一代信息技术开始对传统企业进行更深层次的改造，对企业而言，现在仅仅 “拥抱互联网”是远远不够的。在全球经济进入数字化的时代，数字化转型已经成为企业必须付诸行动的不可忽视的选项。正如同 Hering 所说，企业需要不断地进行迭代和自我革新，能否拥有可持续发展和进化的业务能力将变得至关重要。 这也让越来越多的企业开始接受敏捷和 DevOps 的研发管理方式，来获取更灵敏的市场反应速度和创新能力，因此企业需要采用更有弹性的研发管理模式和培养快速迭代的软件交付能力。知名技术咨询公司 Gartner 也基于这个现象提出了企业敏捷规划（Eenterprise Agile Planning） 的概念，来评估企业敏捷规划发展。这也意味着开发生命周期管理工具（ADLM）从传统的以项目为中心的方式向敏捷和 DevOps 的方向演变，软件交付的方式也从以单个项目的形式转化为了持续性交付。 CODING 同事为客户讲解 CODING 2.0 的产品特性 但是通常，由于研发团队本身与其管理层和业务部门的需求不同，导致企业内部使用的工具不同，这也造成了不同工具间的信息传递不流畅，大量的研发效能被浪费。CODING 作为 EAP 工具的先行者，深耕研发管理领域已久，客户涵盖了互联网、金融、游戏、科研机构、高校、教育等多个重要领域。在为客户服务的过程中，深知企业缺乏完整成熟的工具体系所带来的弊端。 因此在过去的一年中，CODING 和腾讯云等重要合作伙伴及各个领域中大型企业 CTO 进行了深度交流，梳理了企业研发管理中的难点和痛点，并于今天正式推出了 CODING 2.0。 CODING 2.0 提供的企业级 DevOps 解决方案是基于多年项目级 DevOps 经验演化而来，专门为大型企业和项目而设计，CODING 2.0 中包含的 DevOps 全工具链和完整的项目管理功能能将业务、开发、运营团队和管理层整合在一起，并应用自动化流程来简化软件研发流程和管理，从而帮助企业以最低的成本和精力推行大规模 DevOps 实践，实现软件研发的持续性交付。 ...

CODING 为您的企业提供从概念到软件开发再到产品发布的全流程全周期软件研发管理，为您的研发团队提供全程助力，帮助研发团队捋清需求、不断迭代、快速反馈并能实时追踪项目进度直到完成。同时 CODING 还为研发团队中每个角色根据其工作的性质设定了相应的工作流程，帮助每一个人快速上手，助力研发团队，提高研发效能，更高效更快速地进行软件交付。 产品经理的权限设置随着数字化转型浪潮的开始，越来越多的企业开始使用信息化的管理系统取代传统办公工具。在转型的过程中最大的挑战之一就是如何给相应信息设置权限管理，确保不同职能部门的员工只能使用特定的功能，浏览与自身业务相关的信息，不能擅自查看或修改超越权限的内容，保证企业数字资产的准确性、保密性、安全性。 产品经理默认权限： 需求管理在互联网时代背景下，如何快速高效的进行产品研发已经成为每个公司都不得不考虑的问题，在中小型团队中，产品经理往往也会承担起项目经理的职责来对整体项目进行规划，通过 CODING 中的需求管理和迭代模块来制定产品规划并负责该规划的维护和更新。产品经理通过在 CODING 上创建项目来管理产品需求的全生命周期。通过列表的直观呈现，成员可以清楚了解到需求收集任务目前所处的状态，如「需求收集」、「评估中」、「未采纳」、「设计中」、「开发中」、「测试中」和「已上线」等等。 收集与管理需求产品经理将规划上线的功能、用户的反馈以及市场调研的结果整理出来，通过需求管理中需求的形式统一归纳，形成需求池。同时产品负责人对需求池中的需求进行进一步的分析，根据团队习惯将需求分为技术问题、设计问题和产品问题。每一条需求下面会根据需求的复杂程度创建一系列子任务，越重要的需求需要撰写越完整的需求描述。需求收集的需求信息可根据需求进行自定义设置需要反馈的字段，产品经理随着该需求在整个生命周期中阶段的变化，可以在需求中添加「需求类型」、「截止时间」、「预计工时」等信息。并可以为需求添加标签，比如「功能」、「Bug」、「调研」等等。 关键指标进行全面的统计，方便产品经理了解项目的整体进度。 需求文档和原型文件在完成迭代规划后，产品经理即可在 Wiki 中根据迭代中的需求撰写完整的产品功能文档。 同时可以使用 CODING 的文件功能上传分享产品的原型图。 CODING 的文件功能和 Wiki 功能为研发团队提拱了内置的文档协作和团队知识沉淀工具。 制定版本迭代计划在分析完需求后，通过 CODING 中的迭代功能来制定版本发布计划。此时产品团队需要与研发和设计团队召开产品会议，在会议中，产品经理对各个需求进行优先级排序，明确每次版本迭代中需要包括哪些需求、缺陷任务并设定好迭代的周期。一个项目按照开发顺序可以分成不同的迭代。 事务中包含需求、任务和缺陷，迭代提供完整的概览功能可以清晰地展示每个迭代中的事务进行情况和分布。 产品验收在功能完成开发和设计后，便会交由测试工程师进行功能测试，并将相关需求/缺陷状态改成「测试中」。如果测试失败则可以在相关需求下面直接进行评论，给出具体错误信息，将需求转给产品经理或者开发，等待处理。 如果测试通过则可以更新到 Staging 环境中，由产品经理根据需求进行产品验收，验收失败的将回发给负责人协商，讨论是否回退或是重发版。产品经理验收成功后在群内告知测试验收完毕，测试通知运维正式上线。 缺陷管理在测试环节和正式上线之后发现的问题，都可以在 CODING 的缺陷管理模块中归纳统一，并排出优先级作为迭代中的工作来源之一。不过这也要具体问题具体分析，紧急程度高的缺陷需要第一时间反馈到产品进行修复，优先级不高的会安排到接下来的迭代修复。缺陷管理也拥有强大的统计功能，包括缺陷类型、优先级、模块、发现时间等。 立即点击使用 CODING 快速上手，高效交付！

你好，欢迎使用CODING！这份最佳实践将帮助你通过 CODING 更好地实践瀑布流式开发流程。 什么是瀑布流式研发1970 年温斯顿·罗伊斯（Winston Royce）提出了著名的“瀑布模型”，直到 80 年代早期，它一直是唯一被广泛采用的软件开发模型。瀑布模型要求软件开发严格按照【需求→分析→设计→编码→测试】的阶段进行，每一个阶段都可以定义明确的产出物和验证准则。瀑布模型在每一个阶段完成后都可以组织相关的评审和验证。严格的瀑布模型每一个阶段都不能重叠，需要在评审通过后才能进入下一阶段，遵循自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。 瀑布模型的优点是可以保证整个软件产品的质量，保证缺陷能够被提前发现和解决。采用瀑布模型可以保证在整体上充分把握系统，使系统具备良好的扩展性和可维护性。 如何使用 CODING 进行瀑布流式研发管理博弈论（Game Theory）告诉我们看起来利益最大化的策略并不能帮我们达到最好的目标，而是要根据实际情况来制定最合适的策略。同样的，在软件研发管理的战略上，企业并不需要把所有的系统都换成最新、最快的，更重要的是根据业务模式的不同来匹配相应的管理模式和管理工具，让研发和业务能同频共振，而不是互相拖累。 不同部门的 IT 需求侧重点各不相同。比如类似手机 APP 类应用，往往需要更灵敏的市场反应速度和创新能力，因此需要更有弹性的 IT 架构和快速迭代的软件交付能力。相对而言，后台支持性部门比如 ERP、数据库等部门，其业务重心在于保持运营稳定、风险管控以及成本控制。因此，他们的 IT 需求偏重稳定、安全，对于快速响应能力和弹性架构的要求相对较低。这也是瀑布流式研发管理经久不衰的原因。 一、创建项目第一步是在 CODING 中创建一个项目，之后所有的工作都在这个项目中完成。在确认好团队成员后，就可以邀请所有人加入到项目中来。每一个项目都对应独立的代码仓库，因为很多中后台的研发项目会涉及到外部供应商的参与，独立的代码仓库可以确保数据的相对隔离，确保企业数字资产安全。 二、配置权限在邀请完所有成员后，项目经理就需要为不同的角色配置相应的权限。瀑布流研发模式的核心在于安全和可控性，CODING 权限管理功能可以帮助项目管理员方便地根据项目成员的角色来分配相应的权限，减少误操作带来的安全隐患，同时还支持自定义用户组，增加研发管理的可控性。在项目开始的时候，由项目经理先行配置好所有成员的权限，确保团队更有序地进行软件开发。 三、需求文档撰写在配置完所有权限后，项目便正式进入研发阶段。此时由项目经理开始文档的撰写，瀑布流式研发管理模式的特点就是各个阶段都需要完备的文档支持。 如果团队中有产品经理的话，产品经理会通过 CODING 的需求管理功能创建一个需求池。产品经理将规划上线的功能、用户的反馈以及市场调研的结果整理出来，通过需求管理中需求的形式统一归纳，形成需求池。同时项目经理对需求池中的需求进行进一步分析，根据团队习惯将需求分为技术问题、设计问题和产品问题。每一条需求下都会根据需求的复杂程度创建一系列子任务。 产品经理亦可在 Wiki 中根据需求撰写完整的产品功能文档。 同时可以使用 CODING 的文件功能上传分享产品的原型图。 CODING 的文件功能和 Wiki 功能为研发团队提拱了内置的文档协作和团队知识沉淀工具。 四、产品研发 完成产品的原型设计和功能说明文档后，项目经理开始邀请研发团队加入项目，由研发工程师开始进行相关功能的交付开发。如果需求中涉及设计团队，研发工程师可以直接在需求管理页面通过关联功能关联相应的设计任务。 CODING 研发管理系统的代码仓库支持 Git 和 SVN 两种主流版本控制方式，方便各类研发团队快速上手。 瀑布流式研发管理中最看重的一点就是质量。CODING 内置的 Code review 功能和持续集成模块是确保软件研发质量的关键。 Code Review研发工程师开发完成后通过提交 Merge Request 进行代码评审，通过代码评审后 merge 进入 master 分支，确保代码质量。 ...

你好，欢迎使用 CODING！这份最佳实践将帮助你通过 CODING 研发管理系统来更好地实践 DevOps 流程。 DevOps 的本质是打破各个部门之间的隔阂，打通企业的前中后台，推进跨部门协作。CODING 研发管理系统涵盖了企业从需求管理、迭代规划、产品研发，到测试管理、部署管理等软件研发全周期。辅以 Wiki、文件管理等功能，帮助企业打破各个研发小组甚至企业部门之间的边界，让产品经理、研发团队、测试工程师、运维乃至于市场运营、销售、行政等部门共享同一个协作平台，让信息流通更加顺畅，让跨部门协作更加紧密，帮助企业提高研发效能，创造更多的商业价值。 使用 CODING 实践 DevOps从需求构思到产品落地，CODING 研发管理系统引入硅谷最先进的理论，再结合符合中国研发团队的长期积累，为企业提供最优秀的 DevOps 实践，帮助企业将研发效能提升到全新的标准。 同时通过 CODING 的企业微信小程序，还能实现随时随地的同步与协同，通过小程序可以直接查看任务详情、评论任务还能实现允许代码合并（MR）等功能，做到 Coding Anytime Anywhere。 DevOps 的核心在于速度和可控性，CODING 权限管理功能，可以帮助项目管理员方便地根据项目成员的角色来分配相应的权限，减少误操作带来的安全隐患，同时还支持自定义用户组，增加研发管理的可控性。在项目开始时，由项目管理员先行配置好所有成员的权限，确保团队更有序地进行软件开发。 一、迭代规划在邀请所有项目成员加入并配置好相应权限后，正式进入研发阶段。首先要由本项目的产品负责人在需求管理模块中制定项目的产品规划，并负责维护和更新。之后产品团队会通过 CODING 研发管理系统的需求管理功能创建一个需求池。 收集与管理需求产品经理将规划上线的功能、用户的反馈以及市场调研的结果整理出来，通过需求管理中的需求形式统一归纳，形成需求池。同时产品负责人对需求池中的需求进行进一步分析，根据团队习惯将需求分为技术问题、设计问题和产品问题。每条需求下都会根据需求的复杂程度创建一系列子任务，越重要的需求需要撰写越完整的需求描述。 制定版本迭代计划在分析完需求后，通过 CODING 研发管理系统中的迭代功能来制定版本发布计划。此时产品团队需要与研发和设计团队召开产品会议，在会议中，产品经理对各个需求进行优先级排序，明确每次版本迭代中需要包括哪些需求、缺陷、工作和任务并设定好迭代周期。一个项目按照开发顺序可以分成不同的迭代。 事务中包含需求、任务和缺陷，迭代提供完整的概览功能，可以清晰地展示每个迭代中的事务进行情况和分布。 在会议结束后，每个项目成员应该对自己的事务有清晰的认知。 需求文档和原型文件在完成迭代规划后，产品经理即可在 Wiki 中根据迭代中的需求撰写完整的产品功能文档。 同时可以使用 CODING 的文件功能上传分享产品的原型图。CODING 的功能和 Wiki 功能为研发团队提拱了内置的文档协作和团队知识沉淀工具。 二、产品研发在迭代开始后，拿到产品的原型设计和功能说明文档，研发工程师开始进行相关功能的交付开发。如果需求中涉及设计团队，研发工程师可以直接在需求管理页面通过关联功能关联相应的设计任务。 代码托管CODING 的代码托管服务提供高速、稳定且更易用的代码仓库，高性能远端 Git 仓库支持分布式计算和存储，并具有保护分支权限控制等功能。研发团队可以使用 Feature Branch Workflow、Gitflow 和 Forking 等并行研发流程，让团队成员共用一个私有项目仓库进行管理协作，开发者可以选择适合自身的开发流程进行开发。这样的并行开发可以大幅缩短等待时间，提高研发团队的研发效能。 Code ReviewDevOps 的主旨在于快速迭代，在注重速度的同时，质量也是重要的指标之一。开发完成后通过提交 Merge Request 进行代码评审，确保代码质量。通过代码评审后 merge 进入 master 分支。 ...

Git 虽然因其分布式管理方式，不完全依赖网络，良好的分支策略，容易部署等优点，已经成为最受欢迎的源代码管理方式。但是一分耕耘一分收获，如果想更好地掌握 git，需要付出大量的学习成本。即使在各种 GUI 的加持下，也不得不说 git 真的很难，在 V2EX 上也常有如何正确使用 git 的讨论，同时在 Stackoverflow 上超过 10w+ 的 git 相关问题也证明了 git 的复杂性。再加上 git 的官方文档也一直存在着 “先有鸡还是先有蛋” 的问题，虽然文档非常全面，但如果你不知道你遇到的问题叫什么，那么根本就无从查起。 作为国内领先的研发管理解决方案供应商，CODING 一直致力于在国内普及 git 的使用，为软件研发提供更高效率。本文节选自 Katie Sylor-Miller 在日常工作中所遇到过的让他很头疼的 git 相关问题，并整理了相应的应对措施，在这里分享给正在学习如何使用 git 的同学们。当然这些应对措施并不是唯一的，可能你会有其他更好的应对方法，这也恰恰是 git 这套版本控制系统强大的地方。 原文标题：《Oh shit，git！》原文地址：https://ohshitgit.com/我刚刚好像搞错了一个很重要的东西，但是 git 有个神奇的时间机器能帮我复原！ reflog 是一个非常实用的命令，你可以使用这个命令去找回无意间删除的代码，或者去掉一些刚刚添加的却把仓库里的代码弄坏的内容。同时也可以拯救一下失败的 merge，或者仅仅是为了回退到之前的版本。 我 commit 完才想起来还有一处小地方要修改！ 当我 commit 完然后跑测试的时候，经常突然发现忘了在等于号前面加空格。虽然可以把修改过的代码再重新 commit 一下，然后 rebase -i 将两次揉在一起，不过上面的方法会比较快。 我要改一下上一个 commit message！ 当你们组对 commit message 有格式要求时，或者当你忘了中英文间要加空格，这个命令能救你狗命。 我不小心把本应在新分支上的内容 commit 到 master 了！ ...

2019 年 5 月 24-25 日，国内领先的一站式 DevOps 解决方案供应商 CODING 作为腾讯云的深度合作伙伴，受邀参加在成都举行的由 TC608 云计算标准和开源推进委员会主办，中国信息通信研究院牵头，高效运维社区支持，DevOps 标准工作组负责组织的 DevOps 标准体系之系统和工具 & 技术运营标准技术专家研讨会。 在《研发运营一体化 DevOps 能力成熟度模型第 8 部分：系统和工具》与《研发运营一体化DevOps 能力成熟度模型第 4 部分：技术运营》标准技术专家研讨会上，围绕项目与开发管理、应用设计与开发、持续交付、测试管理与自动化写实、技术运营、安全开发等进行了技术研讨，并制定了相关规范。 本次会议专家组合影，第五排左起第四位为 CODING 产品总监王振威 本次会议还邀请了来自华为、平安科技、腾讯、阿里巴巴、中兴通讯、亚信科技、浙江移动、京东金融、中国联通、苏宁消费金融、百度、去哪儿网、新华三等行业顶尖企业的 40 余位 DevOps 实践与工具专家，对标准框架和内容进行了全面的研讨，将系统和工具 & 技术运营两部分标准内容进行完善与规范，并在第二天的会议中将部分内容定稿。 DevOps 能力成熟度模型第八部分 项目与开发管理 & 应用设计与开发此次会议“项目与开发管理”、“应用设计与开发”两个部分的内容依旧由华为、腾讯、阿里、CODING 等单位的专家通力合作完成部分定稿。 工作项管理能力域的部分文稿 持续交付持续交付部分此次主要对能力域及其内容进行了更新，主要包含版本控制系统、构建与持续集成、流水线、制品管理、部署管理、发布管理、环境管理、应用配置管理、数据变更管理 9 个能力域，就数据管理更改为数据变更管理达成了高度一致，完成了定稿目标。其中 CODING 自研的 CCI 系统也为此部分标准提供了参考内容。 会议现场讨论情况 测试管理 & 自动化测试测试管理与自动化测试依旧由中兴通讯、腾讯、亚信科技、CODING 等单位的专家通力合作，完成了测试管理以及自动化测试的最终定稿。 缺陷管理能力域部分文稿 技术运营此次研讨会的核心内容之一是系统和工具中技术运营的能力项划分，最终与会专家达成一致，主要包括通用、监控管理、事件管理与变更管理、配置管理、容量与成本管理、高可用管理、业务连续性管理、用户体验管理等部分，后续也将在中国信通院的指导下，继续开展相关编写以及研讨工作。 会议现场讨论情况 CODING 简介CODING 一站式 DevOps 解决方案 CODING 是面向软件研发团队的研发协作平台，涵盖了软件开发从构想到交付的一切所需，提供完整的研发协作工具，无需对接第三方服务。使研发团队在云端高效协作，实践敏捷开发于 DevOps，提升软件交付质量与速度，降低企业研发成本，助力企业实现数字化转型。 点击即可开启企业数字化转型之旅现五人以下团队可免费使用 CODING

近日，腾讯全年最重要的一场活动——《腾讯全球数字生态大会》于昆明滇池国际会展中心正式举办。此次全球数字生态大会是腾讯战略升级后，整合互联网+数字经济峰会、云+未来峰会、腾讯全球合作伙伴三大行业大会，全新升级打造的行业创新大会。大会围绕产业智慧升级，洞察数字经济发展趋势，分享产业创新的发展成果。 自去年 9 月以来，腾讯完成了第三次组织架构调整，成立云与智慧产业事业群（CSIG），整合了腾讯的云服务、位置服务、安全、大数据等基础能力，深耕企业服务、医疗、出行、教育、零售、政务等垂直行业，全面拥抱产业互联网，立志于为不同规模的企业提供从毛胚房到精装房的各种行业解决方案。本次大会上，腾讯产业互联网各业务负责人集体出动，联袂发布腾讯数字生态业务战略，展示腾讯历经整合与升级后在产业互联网中的最新业务进展。 正如腾讯公司高级执行副总裁、云与智慧产业事业群总裁汤道生在大会演讲中强调的，腾讯的目标是要成为产业的“数字化助手”，提供工具、做好连接、建设生态。CODING 作为腾讯云的合作伙伴和国内领先的企业研发管理解决方案供应商，也将一起探索产业互联网的道路，共建数字生态，共享发展红利。 CODING 在腾讯全球数字生态大会进行产品演示 企业数字化转型离不开专业的工具支持CODING 基于硅谷先进方法与中国团队多年实践共同打造一站式开发体验，涵盖了软件开发从构想到交付的一切所需，使研发团队在云端高效协同，实践敏捷开发与 DevOps，提升软件交付质量与速度，完美契合企业的数字化转型，免去自行搭建工具的烦恼。 精细的项目管理模块 从用户故事和产品需求构想开始，即可在 CODING 中进行全过程精细化的项目管理，一步一步从构思开始制定迭代计划，细化需求和任务，对每次迭代下的相关任务进行多维度的管理，可以对需求任务进行分解、关联、预估工时、讨论等，直至需求开发完成落地，整个项目计划和迭代进度清晰可见。团队成员还可通过团队 Wiki、文件共享等工具进行文档协作、分享，完成团队的每一次产品创意。 研发流程全周期覆盖 CODING 研发管理系统将全套研发流程整合到一个平台，从需求管理、代码仓库、代码评审、测试管理、缺陷管理、持续集成（CI/CD）、持续部署到数据分析、文件管理，全部在一个平台打通，全功能高度整合，提高代码协作效率，保障代码质量，提高交付质量。 研发大数据和可视化报告 CODING 的研发大数据覆盖了需求管理、迭代管理、研发管理、测试管理、缺陷管理等所有模块。自动产出多种可视化报告。通过多种图表形态，多维度衡量项目进度与质量，让工时统计更简单，绩效评定更科学，工作环境更透明。避免填写各种报表导致资源浪费的同时，用数据驱动研发效能提升。 企业级的安全保障CODING 已经为超过 80 万个人开发者和近 4000 家企业提供值得信赖的研发管理系统。解决了金融、保险、地产、互联网和教育等多个领域的软件研发需求。安全更是 CODING 研发管理系统的基石，基于完善的整体规划机构，通过多数据库集群、数据快照、异地备份等多种技术手段和两步认证、用户锁定、操作日志、密码规则设定等功能对用户数据实现了全方面的保护，提升用户数据的安全性。 未来，云服务和基于云实现的各种企业服务都将成为产业互联网的标配，CODING 将协助腾讯云一起，助力各行各业的数字化转型升级，推进技术创新。 点击即可开启企业数字化转型之旅现在五人以下团队可免费使用 CODING

尊敬的 CODING 用户： 您好！ 由于原上游服务商无法满足 CODING Pages 日益增长的用户量以及访问速度需求，同时提供的 DDoS 解决方案无法支撑大型 DDoS 攻击，给 CODING 用户造成了使用上的不便，对此我们深表歉意。 为保障用户使用体验，经过无缝平稳迁移，CODING Pages 服务现已全面升级至腾讯云，为用户提供更加强大的网络资源，加速 Pages 访问，同时优化了防 DDoS 方案，稳定性大幅提升。 CODING Pages 拥有强大的页面托管服务，提供自定义域名、免费 SSL 证书、自动实时部署等功能，使用 CODING Pages 一键托管您的网站，通过实时自动发布您在腾讯云开发者平台中托管的代码，向世界介绍您与您的项目。 目前已有数万开发者、设计师、产品经理、团队与企业在使用 CODING Pages 托管他（她）们的个人网站、博客、企业与产品官网、在线文档等。 点击注册腾讯云开发者平台→ 创建一个项目 → 一键开启 CODING Pages 现在开始面向世界！ 同时 CODING 研发管理系统（企业版）也将在近期支持 Pages 功能，点击体验 CODING 研发管理系统，一站式 DevOps，提升研发效能，五人以下团队免费。 如果在使用 Pages 服务的过程中遇到任何问题，欢迎查阅帮助文档获取相关信息： https://dev.tencent.com/help/doc/quick-start/creating-pages 或者通过以下方式随时向我们反馈： 在线反馈渠道：https://feedback.coding.net 官方邮箱：support@coding.net CODING 团队

写在前面的话其实我也是这两天才接触到Hexo，之前是用的wordpress在阿里云上挂着。觉得Hexo好像更符合现在我的审美，so, do it!嗯前面安装git和node.js我这边就省略掉了。作为一个爱搞事的，这些东西电脑上都有还有就是我照着网上的教程是没问题，但是走到一些页面的小功能的时候，就不起作用了，可能是版本更新不兼容了<!– more –>一. 安装Hexo，初始化npm install -g hexo全局安装Hexo 创建一个文件夹如blog，不用进去（可以用hexo -v检验是否安装成功）hexo init blog 初始化这个blog和文件夹名字要一样，否则又创建个新的npm install安装所需要的依赖后面就 hexo s -g 就是发布之前先生成静态文件 ，s:server，g:generate，访问下localhost:4000看ok不（不起作用，提示什么hexo <commands> 什么东西了，就进到blog的目录下，使用hexo命令）应该没有5了，如果上面没成功，那你去搜搜别人的初始化都怎么弄的，然后再回来看我剩下的实践二. 创建github公开库有个point就是创建Repository的名字格式是 username.github.io，（看到有的博主只用的username就行，你可以尝试一下，不行的话删了就行）比如我的是 dasnnj.github.io，是为了能生成page服务图片描述两步，输入Repository name，然后点击 create repository 按钮图片描述建错删除的话，点进去新建的库，点击setting，点击最下面的删除，需要输入库的名字才能确认删除图片描述没问题的话，还是要点进去setting，往下面滑动到GitHub Pages标题下面，照着那个链接点进去，不出意外就能直接访问到你的这个repository三. 创建腾讯云开发者平台（或Coding）公开库项目地址格式是 username.coding.me，格式不对会404哦，项目名称随便，确定就ok图片描述创建完记得进入代码浏览，初始化一下项目，添加一个readme文档就行了进入page服务，然后开启图片描述四. 配置服务并将文件部署到Github复制上面创建的两个库的git地址修改最下面的deploy，格式类似我这样的# Deployment## Docs: https://hexo.io/docs/deployment.htmldeploy: type: git repo: github: https://github.com/dasnnj/dasnnj.github.io.git,master coding: https://git.dev.tencent.com/dasnnj/dasnnj.coding.me.git,master # 腾讯 # coding: https://git.coding.net/dasnnj/dasnnj.coding.me.git,master # Coding执行hexo clean && hexo g && hexo s 清除缓存，生成静态文件，本地发布页面上没问题的话，就可以执行hexo d会弹出输入github账号密码，和腾讯开发者平台的账号密码。我的只输了一次，可能是我安装了tortoiseGit的原因？好像后面自动给我创建了私钥公钥部署成功，按照各自平台的pages服务提示的网址即可访问五. 其他配置（目前都是关于博客根目录下面的_config.yaml的修改）博客标题title: life is love # 主标题subtitle: 记录生活和学习 # 副标题description: Nothing is impossible, the word itself says I’m possible. # 个人描述keywords: author: Dasnnj # 用户language: zh-CN # 语言，不填默认英文timezone: Asia/Shanghai # 时区urlurl: / #这里如果你只部署了一个平台，那么填那个平台的地址，或者/都行，如果你部署在了两个平台上，那么就只写/吧root: /permalink: :year/:month/:day/:title/ # 链接格式https://newblog.dasnnj.cn/2019/01/26/标题名字/# 也可设置为根据 category/:title/ 分类/标题名字 # category/:title.html会在标题名字后面加上.htmlpermalink_defaults:时间格式date_format: YYYY-MM-DD HH:mm:ss time_format: HH:mm:ss这里给date加上小时分钟等，是为了解决新建页面，发表时间只显示日期没有时间其他# Directory source_dir: source #资源文件夹，这个文件夹用来存放内容public_dir: public #公共文件夹，这个文件夹用于存放生成的站点文件。tag_dir: tags # 标签文件夹 archive_dir: archives #归档文件夹category_dir: categories #分类文件夹code_dir: downloads/code #Include code 文件夹i18n_dir: :lang #国际化（i18n）文件夹skip_render: #跳过指定文件的渲染，您可使用 glob 表达式来匹配路径。 # Writingnew_post_name: :title.md # 新文章的文件名称default_layout: post #预设布局titlecase: false # 把标题转换为 title caseexternal_link: true # 在新标签中打开链接filename_case: 0 #把文件名称转换为 (1) 小写或 (2) 大写render_drafts: false #是否显示草稿post_asset_folder: false #是否启动 Asset 文件夹relative_link: false #把链接改为与根目录的相对位址 future: true #显示未来的文章highlight: #内容中代码块的设置 enable: true line_number: true auto_detect: false tab_replace:新建文章模板的key对应的含义属性 描述title 标题``slug 网址``layout 布局。默认为 default_layout 参数。``path 路径。默认会根据 new_post_path 参数创建文章路径。date 日期。默认为当前时间。我这篇文章的信息title: 将Hexo同时部署在github和腾讯云开发者平台或Coding初级实践教程date: 2019-01-26 20:52:03tags: [Hexo,github,coding] # 标签categories: - tech # 分类持续更新，下面大概要写我的next主题的一些配置，没有网上的大佬那样很全，但是对我来说很足够了（可能是版本不同，网上大佬的有部分可能不适用现在的，我这边会给出我的解决方法）##### 参考hexo的目录结构 - 一直玩编程官方文档 [1]: /img/bVbnQH4 [2]: /img/bVbnQH7 [3]: /img/bVbnQIc [4]: /img/bVbnQId ...