展开

关键词

开发流程规范

这是近期在公司做的一次分享,这几年的互联网开发,算比较幸运,团队一直践行完善这套规范,没有太多的阻碍,得益于公司整体氛围,以及团队对规范和写文档的不排斥,形成了良好的开发习惯 在这次分享后,发现好些大 V也在谈规范,写文档,估计是前段时间阿里又发布了开发手册(华山版),借鉴于一下,对一些细节做些补充,整理出来 整体流程 ? 当然瀑布模型也有天生的缺点:每个阶段的严格性,缺乏灵活性,而现实需求却是经常变化的 所以单纯地选择哪个模型是不可取的,只能根据实际情况出发,为业务提供最大化服务 ---- 细则规范 很多人都在要规范,但好像从没思考过为什么需要规范 无规矩不成方圆,无规范难以协同,比如,制订交通法规表面上是要限制行车权,实际上是保障公众的人身安全,试想如果没有限速,没有红绿灯,谁还敢上路行驶? 写PRD的过程,就是梳理思考的过程,让需求更明确,流程更完整,细节更透彻,这样就不会出现提交给开发时,被开发一堆问题阻塞住。

68330

Git 使用规范流程

团队开发中,遵循一个合理、清晰的Git使用流程,是非常重要的。 否则,每个人都提交一堆杂乱无章的commit,项目很快就会变得难以协调和维护。 下面是ThoughtBot 的Git使用规范流程

51350
  • 广告
    关闭

    腾讯云服务器买赠活动

    腾讯云服务器买赠活动,低至72元1年,买就送,最长续3个月,买2核送4核、买4核送8核

  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    Git 使用规范流程

    团队开发中,遵循一个合理、清晰的Git使用流程,是非常重要的。 否则,每个人都提交一堆杂乱无章的commit,项目很快就会变得难以协调和维护。

    27030

    Git 使用规范流程

    作者 | 阮一峰 团队开发中,遵循一个合理、清晰的Git使用流程,是非常重要的。否则,每个人都提交一堆杂乱无章的commit,项目很快就会变得难以协调和维护。 下面是 ThoughtBot 的Git使用规范流程。我从中学到了很多,推荐你也这样使用Git。 ?

    30210

    功能测试流程规范建设

    测试规范 ? 测试规范,网上随便一搜,都是一堆堆的范文,其实规范也是因人而定,每个人的规范或者依据项目或者部门,需要有特殊性,不过虽然可以定制部分,但是大体还是有很多相似之处,下面这个规范,是笔者之前整理过的一份,如果需要 测试场景设计,针对不同的模块、不同功能、各业务流程和逻辑分支,分别进行测试场景设计。相同的功能在不同的模块,可以参考已有的测试场景进行设计 2. 测试用例设计。 思考该问题是否还在其他场景下复现 提交bug时,各个参数根据bug规范进行填写,summary要简单明了,复现步骤要清晰直接,另外,必要时提供相关测试数据和文字说明,上传图片或附件,以便更加直观的说明问题 其实一份测试规范的内容很多,将目录结构列出后,只是一个指引,其中列出了几项需要关注的点,具体的规范,不一定都要依据如此,但是如果能对你有所启发,那就是晴天~一份好的规范,会让你省去很多不必要的麻烦,希望可以规范的实践起来

    1K20

    项目实施流程规范

    项目实施流程规范主要包含: 1、项目实施管理规范(包含每个项目阶段的主要任务,工作流程,以及相关文档体系管理),落实形成项 。 《系统代码规范》(由技术先出套对应的代码规范,在设计阶段由项目经理参考此规范缩写系统设计报告)。 《集成文档》《测试用例》文档,主要用于测试阶段使用。 (包含基本数据) 3:《项目交付单》 4:《用户使用手册》-按照实施人员提交各部分使用手册。项目经理汇总。 工作流程: 1:如果用户允许的话,让用户签字《交付单》 2:项目经理安排用户体验(建议是二次现场演示和收集问题,合理问题)。 3:针对用户体验进行二次修改。 (二次测试过程反复至结束) 八:系统部署阶段 输入物:系统(含数据库文件,临时许可MAC) 输出物:建议由用户签字确认,《服务器部署清单》《项目交付单》《部署任务单》 工作流程: 1:项目经理根据与用户预约部署时间

    7.6K102

    gitlab合代码规范流程

    一、AG提交代码流程规范: 1.进入远程仓库 http://192.168.120.204:8005 ag自动化组的人用户名分别是: 用户名:sunyb linn gaojs leixc qiaorr 提交代码的注释信息 git commit -m "解释你这次修改了啥东西" # 提交待远程分支 git push origin gaojs-test 4.这个时候,自己本地就是最新的 三、总结 1.这个流程规范是华为那边的规范 v觉得比较规范和好管理, 同步代码方便, 高效协同办公 2.所有的自动化测试人员, 只能通过提MR之后, 管理员review且同意之后, 才能合入主分支, 保证主分支永远是最新代码 3 .可以打tag, 作为基线版本, 以后直接可以通过tag来拉代码持续集成等 4.规范流程和合代码规范, 对大家也是一种技能提升 5.分支管理方便, 切换自由 6.代码规范后续也可以加入, 提交代码 , 必须跑过门禁才允许合入 7.这个流程基本就是和开发的流程基本是一致了 四、Q&A 1.如果提示下面错误Please tell me who you are.: 解决: # 进入.git目录 cd

    9230

    软件测试流程规范

    注:非通用标准流程,仅为大家提供参考。 目标 制定完整且具体的测试路线和流程,为快速、高效和高质量的软件测试提供基础流程框架。最终目标是实现软件测试规范化、标准化。 测试流程说明 流程图 需求分析 需求分析由SA制定,要求细化每一个功能的细节,每一个按钮的位置以及边界范围,对于稍大或稍复杂需求要求建模。 在用例评审中,参与人员需要对用例中与实际功能不符合的用例或者格式不规范规用例提出修改建议。 提交基线 开发人员完成所有功能后,会对自己的功能进行一个自测。自测完成后提交测试进行基线。 说明该项目软件的开发是否达到预定目标,是否可以交付使用。总结测试工作的资源消耗数据:如工作人员的水平级别数量、机时消耗等。 备注 测试团队职责:需求评审、测试计划、测试用例、测试用例评审、测试执行、缺陷报告、缺陷跟踪、测试报告 测试团队交付件:测试计划、测试用例、缺陷报告、测试报告 发布者:全栈程序员栈长,转载请注明出处

    14220

    从零到一,构建你的持续交付流程(一):一个持续交付流程的构思

    持续交付的目标就是从代码编译到可部署的二进包,甚至是部署这个很多都是依赖手工操作的过程自动化,流水线化。 微言码道推出国庆特别系列:从零到一,构建你的持续交付流程 这是第一篇。 手工的方式当然可能多种多样,有些可能还会有非常规范流程约束,但最终仍然避免不了由某个特定的开发或测试或运营人员,以远程登录到服务器的方式,执行某些命令,来达到部署新版本的目标。 那在这个持续交付过程中,是不是可以自动的把代码放到这些工具上去执行,分析并具报告? 甚至更完美点,设定一个质量的标准,只有达到这个标准的才允许继续执行这个流程,没有达到的中止流程。 最终的交付流程如下图所示: 并且,这个交付流程不仅仅是针对某一端,比如只是后端。 我把它应用于整个项目,包括前端,后端都做到了持续交付。 只是前端没有单元测试和API文档,少了一些不需要过程而已。 下一篇:从零到一,构建你的持续交付流程(二):好的工程实践是必要的前提

    21441

    如何绘制符合规范流程图表_流程图画法规范

    流程图可以简单地描述一个过程,是对过程、算法、流程的一种图像表示,在技术设计、交流及商业简报等领域有广泛的应用。流程图可分为:数据流程图和作业流程图。 1、程序流程图的作用 程序流程图的作用程序流程图的作用程序流程图的作用 程序流程图是人们对解决问题的方法、思路或算法的一种描述。 流程图的优点: 采用简单规范的符号,画法简单; 结构清晰,逻辑性强; 便于描述,容易理解。 4、流程图常用的形式有两种:   1)上下流程图   上下流程图是最常见的一种流程图,它仅表示上一步与下一步的顺序关系。    在流程图中,判断框左边的流程线表示判断条件为真时的流程,右边的流程线表示条件为假时的流程,有时就在其左、右流程线的上方分别标注“真”、“假”或“T”、“F”或“Y”、“N”,另外还规定,流程线是从下往上或从右向左时

    12110

    测试思想-流程规范 软件测试缺陷管理流程

    pdf版下载 软件测试缺陷管理流程.pdf

    28420

    从零到一,构建你的持续交付流程(五):使用Jenkins Pipeline,让交付流程与自动化

    本篇,我们将基于Jenkins Pipeline来搭建一个持续交付流程。 在这个交付流程中,我们将做到: 支持手动触发启动这个交付流程 整体流程为:从git代码控制开始,更新代码,编译与构建二进制包,制作docker镜像,重启服务 本篇为从零到一,构建你的持续交付流程第五篇, 本系列其它文章为: 从零到一,构建你的持续交付流程(一):一个持续交付流程的构思 从零到一,构建你的持续交付流程(二):好的工程实践是必要的前提 从零到一,构建你的持续交付流程(三):搭建基于Jenkins +Docker的持续交付环境 从零到一,构建你的持续交付流程(四):利用Docker,将服务容器化 一) 首先,稍微解释下什么是Jenkins与Jenkins Pipeline吧。 至少要补充1-4这四个点,才真正算一个闭环的持续交付。 下一篇:从零到一,构建你的持续交付流程(六):一个闭环的持续交付

    34110

    白盒测试体系-流程规范

    流程规范常伴于我们,小到一次会议,大到团队的管理。当然在白盒测试体系中,流程规范也是最重要的环节之一。 本文将从以下四个方面对白盒测试体系中的流程规范进行分享: 1 什么是流程规范 在白盒测试体系中,流程规范规范了开发、测试、产品需要做的事。 2 为什么要做流程规范 【提高工作效率、保证项目质量】 流程规范看似是降低了个人效率,实则提高了整个项目组的效率。其中规范了每个节点的要求,利于提前发现版本迭代中的问题,降低了问题解决成本。 3 什么时候做流程规范 如果立项之初,就可以做流程规范是最好的。或者可以在项目中发现较多问题的时候做流程规范。 4 怎么推广流程规范 【明确要解决的问题】 针对项目中的问题,进行梳理总结。 【持续优化,不断改进】 随着项目的迭代,需求的变更,应该随时优化流程,不断的改进。之前流程大多依赖于人为推动,但是这里还是建议流程尽量工具化,用系统流程来推动流程规范甚至替代流程规范

    34120

    W3C规范制定流程

    完整流程 W3C Working Group推进Web技术标准化遵循一系列步骤,叫W3C技术报告开发流程。 ? w3c process flow 分为标准化流程、后续修改流程2部分,具体见下文。 W3C Recommendation (REC) W3C建议书是一项规范或要求,经过广泛达成共识,已获得W3C成员和负责人的认可。 Obsolete Recommendation 过时的建议书是W3C认为不具有足够的市场相关性以支持继续建议社区去实现的规范,而不是说存在需要撤销建议书的基本问题。 REC修改流程 建议书发布之后可能需要修改(比如勘误,或者大改),需要走修改流程: // 实质性的变更(大改) 要添加新特性 -> 出第一份WD,从头开始再走整个流程 不添加新特性 -> 经负责人审批回到 建议书修订 工作组可以要求重新发布建议书,否则W3C可能会重新发布建议书,来进行不含对规范文本做任何更改的修正。

    45240

    开发流程与版本管理规范(下)

    四.测试发布流程 产品发布分为两种: Bug 修复或优化 功能特性发布 Bug 修复或者优化发布频率会很高,1~2 天一次。 如果存在影响发布的问题,立即终止本次发布,修改存在的问题,再次测试,提起发布流程。 这种版本的主版本号和次版本号不会发生变化,只有 build number 会增大。 如果存在影响发布的问题,立即终止本次发布,修改存在的问题,再次测试,提起发布流程. Bug 管理 Bug 按严重程度分三个等级 关键, 关键类 bug 影响线上主体业务流程, 必须当天修复。

    56120

    2020-09_Git 使用规范流程

    Git 使用规范流程 在开发过程中,遵循一个合理、清晰的GIT使用流程,是至关重要的。否则,每个人都提交一堆杂乱无章的commit,会增加后期协调和维护的复杂度。 分支提交流程图示 ? 分支合并流程图示 ? 第二章 版本管理 一 发布流程 develop 分支切出 release 分支 release 分支更改版本号并提交 release 分支合并至master 分支 master 分支推送至远程仓库 在 master 分支上打上版本号(tag),推送至远程仓库 二 紧急修复流程 切至出现问题的版本(以1.1.0为例),切出分支 hotfix/1.1.1。

    53130

    git 使用流程规范(merge-request)

    git 使用流程规范(merge-request) 如果你的git workflow 采用此模式,谨记一定要忘记 git merge,除了在 master 分支上 git pull 可以使用 git pull 最后 git rebase --continue 完成 rebase 流程 推送代码到远端 # push 命令加上 --force 参数,因为 rebase 之后,分支历史改变,跟远程分支不一定兼容

    8.2K50

    开发流程与版本管理规范(上)

    不熟悉 git 同事请先阅读 git 的 相关文档: https://gitee.com/progit/ 下面描述公司的 git 的 使用规范。 从 git 角度看,各种分支并不存在特殊性, 只是我们依据我们的开发流程需要产生的一种使用规范

    45020

    从零到一,构建你的持续交付流程(六):让你的持续交付闭环

    ,这是第六篇,本系列其它文章为: 从零到一,构建你的持续交付流程(一):一个持续交付流程的构思 从零到一,构建你的持续交付流程(二):好的工程实践是必要的前提 从零到一,构建你的持续交付流程(三):搭建基于 Jenkins+Docker的持续交付环境 从零到一,构建你的持续交付流程(四):利用Docker,将服务容器化 从零到一,构建你的持续交付流程(五):使用Jenkins Pipeline,让交付流程与自动化 我建议你从自己做起就行了, 二) 在上一章中的持续交付流程中,有几个点我认为是一定要添加上去,以让整个过程闭环。 自动执行持续交付过程 我认为持续交付的执行一定是需要自动触发,也就是 在任何人提交代码之后,马上触发持续交付流程 这样就使整个过程自动化,不需要人手工触发或主动触发这个过程。 下一篇:从零到一,构建你的持续交付流程(终):从零到一,易;从零到一,难

    24451

    软件测试流程规范简介(不同公司流程规范不一样,仅供参考)「建议收藏」

    前言:整理了一下软件测试流程规范简介,仅供参考! 一、流程图概述 二、测试启动阶段(需求分析) 参与软件需求评审、技术评审,以测试的角度分析需求的可测性,可构思将来对测试进行的方法、原则等。 测试人员根据项目大小及项目紧急度商讨测试交付件颗粒度。 四、设计测试用例 根据产品需求文档以及历史业务需要提炼出测试要点,形成测试checklist(提取测试需求),根据测试功能点设计测试用例。 冒烟主要流程测试用例与测试数据,检查主要功能是否已经基本正确实现,初步运行主要功能的性能测试,是否存在明显的性能缺陷。对测试发现的问题定时进行归纳与总结,预测以后测试可能会存在的风险。 备注:测试流程将在以后的测试项目中慢慢的修正和完善,一旦进入测试过程中,不接受任何大模块更改,如需更改需求请走需求变更流程

    5510

    相关产品

    • 商业流程服务

      商业流程服务

      商业服务流程(BPaaS)是一项云资源的审批流程服务,可以帮助您管理账号下的资源申请与分配。您无需创建多个腾讯云账号管理不同业务的资源,而是在一个腾讯云账号下管理和分配资源。管理员创建不同的资源审批流,申请人根据业务需求发起流程,审批通过后即可进行资源的分配。

    相关资讯

    热门标签

    活动推荐

    扫码关注腾讯云开发者

    领取腾讯云代金券