StarRCXT使用指南
Star-RCXT使用指南单元库设计B组：张真华马艳
目录
Star-RCXT使用指南 (1)
1 .Star-RCXT概述 (3)
功能 (3)
2 .使用环境及所需文件 (3)
3 .运行流程 (4)
Hercules 流程 (4)
CCI (Calibre Connectivity Interface)流程 (9)
4 .更多StarRCXT命令选项 (12)
Extraction命令 (13)
Processing 命令 (13)
Netlist命令 (13)
5 .StarRCXT运行过程中常见问题 (13)
6 .帮助文档 (15)
1 ． Star-RCXT概述
Star-RCXT是一个集成电路版图寄生参数提取工具，并且生成一个带有版图寄生参数的网表供时序和噪声分析。
功能
1、可以完成精确的全芯片的噪声、时序、电压降分析。
2、有选择的对关键路径进行参数抽取和分析。
3、适用于各种设计类型如ASIC、全定制、存储器和模拟设计。
4、提供层次化和分布式处理。
2 ．使用环境及所需文件
说明：
1、Star-RCXT 可以直接读取Milkyway ，LEF/DEF, Calibre Connectivity Interface（CCI）和Hercules流程所产生的数据库。
2、TCAD_GRD_FILE是一个以nxtgrd为扩展名的文件，其中包含了对方块电阻等工艺
参数的定义的工艺文件（ITF）的内容, Star-RCXT就是基于这些工艺参数进行计算。
3、MAPPING_FILE是一个以map为扩展名的文件，是TCAD_GRD_FILE中的层名和LVS runset文件中定义的层名的一个映射。不同的LVS runset文件需要定义不同maping文件。
4、star_cmd是一个包含所要执行命令的文件，通常用在命令行方式下，可以通过添加修改文件中的命令来达到所需应用。
5、Star_RCXT有SPF、SPEF、SBPF等输出格式。
3 . 运行流程
运行流程有以下几种：Milkyway Database Flow、LEF/DEF Database Flow、Hercules Database Flow、Calibre Connectivity Interface (CCI) Flow。各个流程的主要区别是各自生成的含有版图信息的数据库不同。
Hercules 流程
1、在hercules lvs runset 文件中找到如下语句并将值设为TRUE：
(以/*开头的为注释语句。)
/*Set to “TRUE” for Hercules StarRCXT TR ；level RC flow*/
V ARIABLE string STARRCXT =”TRUE”;
这行命令将会在执行LVS的同时生成一个带有LAYOUT信息的Milkyway Database。
2、运行LVS。（过程参见验证工具使用指南）
完成后将会在运行目录下生成一个和BLOCK名称相同的文件夹，这就是StarRCXT可以直接读取的Milkyway Database。
3、运行StarRCXT（图形化界面方式）
＃StarXtract -gui
将会看到如下界面：
选择Setup－〉Single Shot
红色的为必填项目：BLOCK是要抽取参数的模块或单元名称；MILKYWAY DATABASE是通过LVS产生的，将路径填入即可。也可用Browse按钮来选择。
接着选择Extraction选项
红色选项中填入相应文件路径（相关介绍见使用环境及所需文件）。EXTRACTION选项控制提取参数的类型，有3个选择R、C、RC分别对应只提电阻、只提电容和同时提电阻电容。REDUCTION选项对结果没有实质影响，选择YES可将某些节点参数值进行合并，对
参看生成的spf文件会有帮助。然后进入下一个选项Processing。
POWER NETS 必须指定，名称要和LAYOUT中一致，如不指定StarRCXT将把电源和地当作输入输出PIN抽出，导致后仿真失败。在Netlist选项中会看到：
本栏目中NETLIST FILE指定抽出结果的文件名（可以是任何名称），NETLIST FORMAT 选择SPF。最后进入Xref选项。
XREF选择YES，CELL TYPE 和NET TYPE 都选LAYOUT,使抽出的节点名称和LAYOUT中的保持一致。红色的两个选项和LVS有关，运行LVS时会产生一个RUN_DETAILS文件夹，里面包含了一些错误信息以及evaccess和compare，将其路径填入即可。
Noise、 Field Solver、Clock Analysis、 Power Analysis、 Simulation由于现有的License 没有提供相应功能所以在此不多加解释。
以上命令即可完成基本的参数抽取。并可以通过主菜单下的SA VE命令保存为一个
star_cmd文件（文件名可以任意）
文件内容如下
最后点击主界面下Run
然后点击Clean All表示清除上一次运行过程中产生的数据，点击OK即开始运行。
4、运行StarRCXT（命令行方式）
＃StarXtract –clean starcmd
说明：－clean 表示清除上一次运行过程中产生的数据，starcmd则是命令文件，可以在图形化界面下生成也可以直接用文本编辑器写出。
5、两种方式的比较：图形化界面直观但效率较低适合初学时使用，命令行方式简洁高效推
荐使用，在做大量相同需求的工作时优势尤为突出，比如单元库，可以写好一个starcmd 文件然后只需修改BLOCK、MILKYWAY_DATABASE、NETLIST_FILE就可以完成不同的单元参数抽取。
CCI (Calibre Connectivity Interface)流程
Calibre 是Mentor Graphics的验证工具，它无法直接生成可以被StarRCXT直接读取的数据库，因此需要由CCI query server来生成以下文件
z AGF ——类似于GDS的包含版图中的多边形信息（包含连接性）的文件
z GDS_MAP file ——映射AGF文件中的层号和规则文件中的层名。
z NL file ——包含节点ID号的类似于spice网表的文件
z IXF file ——只被用于XREF（device info）
z NXF file ——只被用于XREF（net info）
z Ports_cells file ——顶层端口信息
z LNN file ——映射节点名和节点ID号
z DEVTAB file ——包含器件的层信息
详细信息请参见Star-RCXT_CCI_Training.pdf
1、运行LVS
?Flat LVS（具体参见Calibre验证）
＃calibre –lvs cal.rul | tee lvs.log
说明：cal.rul为runset文件
lvs.log为生成的日志文件
?Hierarchical LVS
＃calibre －lvs －hier －automatch cal.rul
注意：在lvs runset文件中找到如下语句
MASK SVDB DIRECTORY “svdb” QUERY
在最后加上CCI表明是CCI流程（此语句没加）。或者在图形化界面下找到如下选项并激活
2、运行query server导出一些信息提供给Star-RCXT
#caliber –query svdb 说明：svdb是运行LVS产生的数据库；query.cal是query命令文件（如下所示），运行结果就是生成了以上介绍的8个文件。 Query.cal： /*在AGF（annotated GDSII）文件中定义各种属性位置（ID）*/ GDS NETPROP NUMBER 5 GDS PLACEPROP NUMBER 6 GDS DEVPROP NUMBER 7 /*如果runset文件中用原始层作为中间层需要将其初始化*/ GDS SEED PROPERTY ORIGINAL /*导出AGF mapping文件供Star－RCXT使用*/ RESPONSE FILE ./~/GDS_MAP GDS MAP RESPONSE DIRECT /*导出AGF文件*/ GDS SEED PROPERTY ORIGINAL GDS WRITE ./~/*.agf /*导出器件所用层的信息*/ RESPONSE FILE ./~/*.devtab DEVICE TABLE RESPONSE DIRECT /*导出layout中节点名和节点号的映射文件*/ LAYOUT NETLIST TRIVIAL PINS YES LAYOUT NETLIST EMPTY CELLS YES LAYOUT NETLIST NAMES NONE LAYOUT NAMETABLE WRITE ./~/*.lnn /*导出layout中的netlist*/ LAYOUT NETLIST PRIMITIVE DEVICE SUBCKTS YES LAYOUT NETLIST PIN LOCATIONS YES LAYOUT NETLIST HIERARCHY AGF LAYOUT NETLIST WRITE ./~/*.nl /*导出节点与晶体管之间的交互信息*/ NET XREF WRITE ./~/*.nxf INSTANCE XREF WRITE ./~/*.ixf /*导出端口信息*/ PORT TABLE CELLS WRITE ./~/*.ports_cells 3、运行StarRCXT选择Setup下Timing选项并选择Calibre，出现如下窗口。 在各个栏目里填入相应信息，CALIBRE RUNSET 写入Calibre LVS runset文件，其他栏目相应填入先前生成的文件路径。注意CALIBRE AGF CELL EXTENTS直接由LVS日志文件给出(在常见问题中会有详细解释)。 继续文件路径的输入，关于TCAD GRD FILE 和MAPPING FILE请参见“使用环境和所需文件”。NETLIST FORMAT 选择spf。COUPLE TO GROUND 是对地耦合电容可根据需要自由选择。NETLIST FILE 填入所要生成的文件名，一般是和BLOCK名相同，以.spf为扩展名的文件。 XREF选择YES。点击OK在主菜单下选择FILE－RUN 以上即是最基本的流程 4 . 更多StarRCXT命令选项 StarRCXT命令分为Database 、Extraction 、Processing 、Netlist等几类，各个流程的命令 会有略微不同，以下主要以Calibre流程为主。范围主要是常用命令，需要了解更多命令请参照strm_2003.6.pdf. Extraction命令 此类命令中影响结果主要是IGNORE_CAPACITANCE 本命令只对晶体管级的提取产生作用，它有3个选项：ALL、DIFF、NONE。作用分别是禁止抽取有源区之间有源区到衬底、栅到有源区栅到衬底之间的电容；禁止有源区到衬底有源区之间的电容，栅的电容将保存；不忽略任何电容。可参见下图所示。进一步的解释请参见strm_2003.6.pdf. P81。 Processing 命令 这类命令中POWER NETS值得注意，它的作用是将vdd和vss指定为POWER NETS在提取中电源地的提取。 NETS命令的作用是指定提取的节点名称，用于对关键路径的提取。 Netlist命令 此类命令不会影响抽取结果，但是可以方便查看结果，如有需要可参照strm_2003.6.pdf。 5 . StarRCXT运行过程中常见问题 1、LVS runset文件设置错误：检查下列语句是否存在 MASK SVDB DIRECTORY “svdb” QUERY CCI 或者在图形界面方式下检查CCI选项是否被选上 2、执行Query server发生错误：确认上述问题不存在并且顺利通过LVS的情况下确认执行 目录下有svdb文件夹存在，否则检查上一步。 3、运行StarRCXT中发生意外中断：首先查看.star_sum文件，如果错误结果显示ERROR： Faile to creat HN 请检查BLOCK名称。 如果错误结果显示ERROR：Can not open file /~~~ 请检查Query server所生成的文件路径在starcmd文件中是否正确 如果错误结果显示ERROR：XXX layer has no connections ERROR：Map layers Failed 请检查maping file 注：maping file 是统一给定，通常情况不需修改。如发生以上问题请到指定目录复制4、SPF文件问题：如果发生.SUBCKT中端口名称没有提出或没有正确提出（与layout中 不符），请检查starcmd文件中CELL_TYPE和NET_TYPE两个选项是否被指定为LAYOUT。如果是那么请检查layout中PIN及其名称是否正确打上，或者TEXT是否打 在正确位置。 注：如果使用PIN，那么注意PIN的名称(标识)必须和PIN使用同一层，比如M1。 如果发生在spf文件中提出了vdd和gnd的信息，请检查starcmd中是否有POWER_NETS：vdd! gnd! 这一选项。如果有请检查LAYOUT中的电源地名称是否和starcmd 中一致。 5、CALIBRE_AGF_CELL_EXTENTS： 此选项需要填入单元边界左下角和右上角的坐标，这里指的单元边界是指一个正好能套住所有layout中的多边形的矩形框。其坐标值会在LVS日志文件显示： 日志文件可以在运行LVS时加入‘| tee lvs.log’生成： ＃calbre –lvs cal.lvs | tee lvs.log 如果在图形化界面下那么直接可以在主界面窗口下看到全部运行日志。 此信息也可以在layout中直接测量获得，在starcmd文件中的标准填写格式是： -0.48 -0.11 7.48 4.75 6 . 帮助文档 1、strm_2003.6.pdf 2、stug_2003.6.pdf 3、Star-RCXT_CCI_Training gitlab使用指南 1 gitlab介绍 GitLab 是一个用于仓库管理系统的开源项目，使用Git作为代码管理工具，并在此基础上搭建起来的web服务。 GitLab是基于网络的Git仓库管理工具，且具有wiki和issue跟踪功能。使用Git作为代码管理工具，并在此基础上搭建起来的web服务。 GitLab，它使用Ruby语言写成。后来，一些部分用Go语言重写。 2应用特点 1.Web框架使用RubyonRails。 2.基于MIT代码发布协议。 3.需要gitolite协同工作 3优点 GitLab为整个DevOps生命周期提供解决方案 1.管理 统计和分析功能。 GitLab提供统计数据和洞察力，以帮助提高GitLab在组织中的价值。 2.计划 项目计划和管理功能。 使用GitLab灵活的项目管理工具可视化，确定优先级，协调和跟踪进度。 3.创造 源代码以及数据创建和管理功能。 将源代码整合到一个易于管理和控制的分布式版本控制系统中，而不会影响工作流程。GitLab的Git存储库附带分支工具和访问控制，可为项目和代码的协作提供可扩展的单一事实来源。 4.校验 测试，代码质量和持续集成功能。 内置的静态代码分析，代码测试，代码质量，依赖项检查和Review Apps可以更快地发现错 误，提高安全性并缩短反馈周期。自定义您的批准工作流控件，自动测试代码质量，并为每个代码更改启动过渡环境。 GitLab持续集成是下一代测试系统，可以扩展以更快地运行测试。 5.包 Docker容器注册表。 GitLab软件包允许组织将GitLab用作各种常见软件包管理器的专用存储库。用户能够构建和发布程序包，这些程序包可以很容易地作为下游项目中的依赖项使用。 6.发布 应用程序发布和交付功能。 花更少的时间配置工具，而花更多的时间创建工具。无论要部署到一台服务器还是数千台服务器，都可以通过GitLab内置的持续交付和部署来自信，安全地构建，测试和发布代码。 7.配置 应用程序和基础结构配置工具。 使用GitLab Auto DevOps自动执行从构建到部署和监视的整个工作流程。最佳实践模板可帮助您从最小到零的配置开始。然后自定义所有内容，从构建包到CI / CD。 8.监控 应用程序监视和指标功能。 确保应用程序始终响应并可用。 GitLab会收集并显示已部署应用程序的性能指标，因此可以立即知道代码更改如何影响生产环境。 9.安全 安全功能功能。 检查应用程序是否存在安全漏洞，这些漏洞可能导致未经授权的访问，数据泄漏和服务拒绝。GitLab将对应用程序代码执行静态和动态测试，查找已知缺陷并在合并请求中报告这些缺陷，以便可以在合并之前修复它们。安全团队可以使用仪表板来获得项目和组的高级视图，并在需要时启动补救过程。 4运行gitlab gitlab-ctl start 微服务开发手册 1．开发说明 ●所有服务均基于springboot框架开发。Springboot内嵌了tomcat服务器，无需生成war包，并简化了maven配置，能够让开发者快速入手spring的开发。 ●服务的接口定义需严格符合restful规范。rest规范参考第2节restapi接口规范 ●所有服务都需要在注册服务上注册，否则不能被其他服务所调用。同时平台也能够实时监测服务的状态，能够及时预警及调度资源。 ●所有服务的配置信息统一保存于gitlab上，并通过配置服务获取配置。 ●对数据库的操作统一采用MyBatis?框架。MyBatis是个支持普通SQL查询，存储过程和高级映射的优秀持久层框架。Springboot也提供了mybatis的集成方案，可以很快捷地整合mybatis到项目中。 ●包名约定：所有包均以.服务名为父包名 ●所有项目基于来开发。项目的管理与构建采用maven，代码统一托管于gitlab仓库。 2．restapi接口规范 springboot接口设计需符合restful风格。在RESTful架构中，每个网址代表一种资源（resource），所以网址中不能有动词，只能有名词，而且所用的名词往往与数据库的表格名对应。 而客户端要执行某种类型的操作，需要根据http的操作协议来决定。HTTP提供 了常用的几种操作，如下表： 对数据库的增删改查操作，应该严格遵守上面定义的五种HTTP动作。 对于更新动作，参数通过requestbody来传递，格式为json。服务端返回数据格式也均为json。 服务端返回数据对象约定： publicclassUnifyInfo{ privateintcode; 私有 版权声明 。 Copyright 2016? Copyright 商标声明 本书所提到之商标，皆属於原合法注册公司所有。 Trademarks All brand names and product names used in this book are trademarks, registered trademarks, or trade name of their respective holders. 免责声明 。 LIMITATION OF LIABILITY . 修订记录 目录 GIT提交流程: microservice-test(master) -> dev-story-FEIEH-365 [-> ?rmus-integration] -> ?rmus-qa -> microservice- test(master) 前提 所有story、task分?支都要在最新master（本项?目暂时以microservice-test作为master）分?支上切取 未上线的任务出现bug，直接从?rmus-qa拉出分?支来进?行行修复 已上线的任务出现bug，从master拉出分?支来进?行行修复 所有的分?支创建都需要在gitlab上进?行行（保证是基线分?支是最新的） 所有的分?支创建都需要在gitlab上进?行行（保证是基线分?支是最新的） 所有的分?支创建都需要在gitlab上进?行行（保证是基线分?支是最新的） 分?支命名规范 1. 任务故事分?支:格式为dev-story-FEIHE-任务号，如dev-story-FEIHE-365 2. 集成测试分?支:格式为?rmus-integration，域名为?rmus-wxshop 3. 测试分?支：固定为?rmus-qa，域名为?rmus-test 4. ?生产分?支：固定为microservice-test 操作说明 1. 接任务?比如说现在的任务号是365，拉取最新的microservice-test分?支，然后切出最新的?自?己故事任务分 ?支dev-story-FEIEH-365; 2. 在任务完成后提交代码到当前dev-story-FEIHE-365并推送到远端; 3. 本地开发完成但需要联调测试的任务，从任务分?支dev-story-FEIHE-365发起merge request到?rmus- integration，如果有冲突则切换到?rmus-integration分?支并拉取最新代码(如果没有，重新切换拉取最新代码)作为备?用，在当前分?支使?用GIT的merge命令将?自?己的dev-story-FEIHE-365分?支代码合并到此分?支(Idea内操作?见图1) 本地GitLab服务器找回GitLab管理员账户密码的方法在之前的文章中提到过公司因为项目管理的问题增加了本地的GITLAB服务器，也提到了本地GITLAB服务器中个人账户的秘钥设置，本次我们就说一下本地GitLab服务器找回GitLab管理员账户密码的方法。 一般GitLab服务器找回密码可以通过系统自带的找回密码进行找回，不过GitLab服务器的超级管理员一般都是admin@https://www.wendangku.net/doc/1210846737.html,这个名称，https://www.wendangku.net/doc/1210846737.html,这个域名不是我们的，对应的邮箱也不能正常使用，所以我们就没办法通过邮件来进行找回了。 1、首先我们登陆服务器，使用su-git切换到git用户下操作 2、登陆后可以通过ls查看gitlab的文件，我们直接使用gitlab-rails console production进入gitlab控制台，输入命令后需要等待 Loading production environment(Rails x.x.x)等字样的显示，不然gitlab的查询语句不会被解析。 3、输入user=User.where(id:1).first，意思就是查询id为1的用户，一般情况下超级管理员用户都是1，当然也可以使用username来查询用户，在管理员账户对询到后，可以通过返回的信息中看到admin为true，username为Administrator，当然也有的是admin，我们需要确认的就是admin为ture即可。Tips，常用的还有user=User.all查询所有用户，where条件有username email state user=User.where(id:1).first user= User.find_by(email:'admin@local.host')等，可以根据自己需要进行选择。 一、环境说明 二、文档概述 三、场景示例 场景一：通过root管理员创建一个管理员用户（GitLab页面） 场景二：初始化Group、Project、User、Permission信息 （GitLab页面） 场景三：上传项目代码（Eclipse界面） 场景四：创建新分支（GitLab页面） 场景五：处理分支合并请求（GitLab页面） 场景六：合并分支（Eclipse界面） 一、环境说明 GitLab访问地址：http://192.168.251.151:8181 不同版本的gitlab在操作页面的排版上会有些变化，但操作意义相同二、文档概述 本文档意图说明管理员在git使用过程中常遇到的场景及操作。包括以下场景： 场景一：通过root管理员创建一个管理员用户（GitLab页面） 场景二：初始化Group、Project、User、Permission信息（GitLab页面） 场景三：初始化上传项目代码（Eclipse界面） 场景四：创建新分支（GitLab页面） 场景五：处理合并分支请求（GitLab页面） 场景六：合并分支（Eclipse界面） 三、场景示例 场景一：通过root管理员创建一个管理员用户（GitLab页面） 1、root用户是GitLab最高权限管理员，为了便于管理，一般单独创建一个管理员权限的用户对GitLab进行操作。 2、root用户登录，点击进入AdminArea即管理员区域，可以在此区域查看Gitlab信息概览，对项目、用户、组进行管理等，如图所示： 2、点击NewUser创建用户，填入Name、UserName、Email必须信息，其他根据需求设置，一般保持默认，如果是新建管理员用户，则将Access栏的AccessLevel设置为Admin。如图所示： 3、设置完成，点击CreateUser即完成创建用户。创建的用户会收到邮件，根据邮件内容访问设置密码后即可登录访问。（可能被拦截为垃圾邮件，如果确认未收到邮件，检查GitLab邮箱功能设置---见《GitLab安装配置》） Gitlab使用手册 目录 一Gitlab账号/库申请流程 (3) 1.1 Gitlab账号申请 (3) 1.2 Gitlab库申请 (3) 二Gitlab登录 (3) 2.1 Gitlab 访问路径 (3) 2.2 Gitlab登录页面 (3) 三Git环境配置 (4) 3.1创建公钥 (4) 3.1.1 Linux环境 (4) 3.1.2 Windows环境 (4) 3.1.3 MacOS环境 (7) 3.2 Gitlab SSH页面配置 (7) 四Git操作命令 (8) 4.1 Git本地仓库操作命令 (8) 4.1.1 git init/git clone 初始化库 (8) 4.1.2 git status 查看状态 (9) 4.1.3 git add 添加文件 (9) 4.1.4 git diff 对比文件 (9) 4.1.5 git commit 提交更新 (10) 4.1.6 git rm 移除文件 (10) 4.1.7 git mv 移动文件 (11) 4.1.8 git log 查看提交历史 (11) 4.1.9 git reset 撤销操作 (12) 4.1.10 git branch 创建分支 (13) 4.1.11 git merge 分支合并 (13) 4.1.12 git conflict 解决冲突 (14) 4.1.13 git tag 创建标签 (14) 4.2 Git远程仓库关联操作命令 (15) 4.2.1 git remote 查看远处仓库 (15) 4.2.2 git remote show 查看远程仓库信息 (15) 4.2.3 git remote add 添加远程仓库 (15) 4.2.4 git fetch 从远程仓库抓数据 (16) 4.2.5 git pull 获取最新版本 (16) 4.2.6 git push 推送数据到远程仓库 (16) 4.2.7 git remote rename/rm远程仓库重命名/删除 (17) 测试任务交接说明 为规范研发测试任务交接过程，提高相应工作效率现明确交接过程中的相应要求。 1．任务交接流程 2．任务交接过程说明 a)提交准备 任务提交人员需填写《测试任务申请单》 b)提交测试 发送任务交接邮件，邮件接收人包括研发相关人员、项目经理、测试经 理，抄送提交人所属部门经理 c)原型确认 产品部产品经理回复提测邮件，在邮件中说明研发提测中原型参照是否 正确 d)接收测试 交接单审核通过后，测试经理分配任务，回复全部邮件并加入任务负责 人为邮件接收人，提交人如未接收到回复的邮件，则表示该任务还未进 行分配 e)追加测试 任务提交人员填写原《测试任务申请单》追加测试部分，并修改计划上 线日期，将修改后的《测试任务申请单》回复在该任务以往邮件后方 f)测试完成 测试人员出具测试报告，并将《测试报告》回复在该任务以往邮件后方， 该任务结束 3．任务单填写说明 a)计划上线时间：应为晚于提交日期后的日期，原则上不接收提交任务当 天上线的情况； b)测试类型：按实际测试类型选择，并各类型在测试需求栏中需有对应的 说明，如无说明，则认为该次任务不包该类型测试； c)需求来源：按实际来源进行选择 i.为产品的，提测时需同时提供原型图、UI 图示、产品需求说明，原 则上至少为非UI图示的其中一种； ii.为研发的，提测时需同时提供合格的《需求说明书》； iii.为问题修复的，即修复线上出现的问题； d)测试需求：详细描述被测对象相关需求 i.功能需求：包括但不仅限于业务功能描述、场景说明、业务逻辑、 校验规则、受限条件等； ii.性能需求：包括但不仅限于压力场景、并发量、性能指标等； iii.接口需求：包括但不仅限于接口功能、访问方式、请求报文等； iv.安全需求：描述所需测试的功能模块； e)测试版本：被测对象GITLab中项目的Http访问地址,性能被测版本应为 已完成测试的稳定版； f)外围版本：被测对象可运行的最小依赖外围系统版本号，需为具体的版 本号或tag版本，其它方式不接收； g)内验方式：即研发内部验收的方式，需提供测试环境地址，所用测试数 据，原则上不接收研发人员个人开发环境作为内部验收环境； h)追加需求：同测试需求； 4．任务结束说明 a)计划上线日期当天15:00为封版时间，该时间后不再接收版本更新，原 则上以该版本最终测试结果出具测试报告，该次任务结束； b)当次任务所提需求已全部覆盖、所设计用例或大纲全部执行、缺陷管理 系统中BUG记录全部处理完毕，依据结果出具测试报告，该次任务结束； Windows下Git和Gitlab简单教程 ---jack杨俊伟在使用之前，因为大家之前用的都是SVN集中式的版本控制系统，而git是分布式的，但在使用和功能上差异没有特别大，这里需要先简单了解它们的差异。 1)最核心的区别Git是分布式的，而Svn不是分布的。Git跟Svn一样有自己的集中 式版本库和Server端，但Git更倾向于分布式开发，因为每一个开发人员的电脑上都有一个Local Repository,所以即使没有网络也一样可以Commit，查看历史版本记录，创建项目分支等操作，等网络再次连接上Push到Server端。 2)Git把内容按元数据方式存储，而SVN是按文件：因为,.git目录是处于你的机器上 的一个克隆版的版本库，它拥有中心版本库上所有的东西，例如标签，分支，版本记录等。.git目录的体积大小跟.svn比较，你会发现它们差距很大。 3)Git没有一个全局版本号，而SVN有。Git的内容的完整性要优于SVN: GIT的内 容存储使用的是SHA-1哈希算法。这能确保代码内容的完整性，确保在遇到磁盘故障和网络问题时降低对版本库的破坏。Git下载下来后，在OffLine状态下可以看到所有的Log,SVN不可以。 4)SVN必须先Update才能Commit,忘记了合并时就会出现一些错误，git还是比较 少的出现这种情况。 5)克隆一份全新的目录以同样拥有五个分支来说，SVN是同时复製5个版本的文件, 也就是说重复五次同样的动作。而Git只是获取文件的每个版本的元素 6)提交（Commit）在SVN，当你提交你的完成品时，它将直接记录到中央版本库。 当你发现你的完成品存在严重问题时，你已经无法阻止事情的发生了。如果网路中断，你根本没办法提交！而Git的提交完全属於本地版本库的活动。而你只需“推” 使用Git开发项目流程说明 一、一次性操作 1.公司相关负责人在gitlab上面创建新项目，并进行初始化<远程公共> 2.员工fork该项目<远程自己> 3.员工clone自己fork的项目：git clone <远程自己项目git地址> <项目名称> 4.增加remote：git remote add public <远程公共项目git地址> 二、每次开发必须操作 5.拉取远程公共最新代码：git pull public master --rebase 6.员工进行项目开发 (1)创建+切换分支：git checkout -b<本次开发分支名> (2)开发 (3)测试结果并通过 (4)添加跟踪文件：git add . (5)提交本次开发：git commit -m '描述' 7.切换到开发主分支：git checkout master 8.拉取远程公共最新代码：git pull public master --rebase （同【5】） 9.合并代码 (1)保留分支提交记录，合并后不需要提交代码：git merge <本次开发分支名> (2)不保留分支提交记录，合并后需要重新提交代码： ①git merge --squash <本次开发分支名> ②git commit -m '描述' 10.测试结果并通过 11.push到远程自己：git push 12.删除本次开发分支：git branch -d <本次开发分支名> 13.本次开发完成 三、开发完成后的操作 14.发起远程公共合并申请 15.公司负责人审核代码并操作 四、常用命令参考 16.Git 配置信息 (1)全局设置用户名：git config --global https://www.wendangku.net/doc/1210846737.html, "用户名" (2)全局设置邮箱地址：git config --global user.email "邮箱地址" (3)查看系统配置：git config --system --list (4)查看当前用户配置：git config --global --list (5)查看当前仓库配置：git config --local --list 17.查看工作区的状态：git status 18.查看修改内容：git diff 19.本地分支 (1)重命名：git branch -m <目标分支名> <新的分支名> (2)推送本地分支到远程分支：git push origin master (3)把本地tag推送到远程：git push --tags (4)获取远程tag：git fetch origin tag 容器技术与用户自服务平台建设方案 如何减少运维团队的日常琐事？如何将服务平台化，赋予用户自我服务的能力？新东方云利用Rancher容器管理平台、Harbor镜像仓库和GitLab构建企业应用商店。赋能运维团队和用户，尝试破解用户自服务的难题。 开场先讲个小故事： 运维团队一线支持小哥接到某团队的工单，要求部署一套TiDB做功能测试。小哥在云平台上申请机器，按照内部标准的部署文档安装配置，最终交付给该团队。小哥回复邮件后已经是下午3点多了，小哥的一天就这么过去了。平淡无奇的运维工作似乎就应该是这样的。 我相信这是大多数运维团队都会面临的问题，运维团队面临着很多不断重复，事务性的工作。组织规模变大以后，像这样有的没的项目都会来运维团队寻求支持。运维团队招了很多人，忙了一年下来，发现好像也没做成什么事情，功劳似乎都是别人的，成本都是自己的。为什么会这样？因为运维团队的大量时间和精力在服务其他团队的琐事中消耗掉了。 这是建设新东方云的初衷之一。我们设想是否能把手中的资源和我们的服务平台化？通过定制和开发，最终我们交付出去的不是针对具体项目的劳务，而是一个服务的平台。让大部分重复性的日常部署和维护工作由用户自己完成。我们将运维能力直接赋予其他团队和用户，让运维团队能将精力集中在提高SLA和技术提升上。 这也是我今天分享的主题，今天主要分享一下新东方利用容器技术在用户自服务方面的一些探索。 首先简单介绍一下新东方云和容器云服务： 新东方云采用自建数据中心+IDC+公有云的混合云架构，提供包括：云服务器、对象存储、分布式文件系统等IaaS层面的服务，提供消息队列、缓存服务等中间件层面服务，以及运维大数据方案和视频服务等等。 容器云服务是新东方云提供的最新服务，目前还在beta阶段。我们的容器云平台也是基于Docker、Harbor等主流技术作为后台，使用Rancher提供的Cattle作为编排引擎。 提到Rancher大家可能也听说过，简单介绍一下Rancher。 Rancher是一个轻量级的容器管理平台，CNI兼容的网络服务、存储服务、主机管理、负载均衡等功能。Rancher现在分为两个分支： 1.X：采用Rancher自己开发的Cattle编排引擎，已经有一套完整的平台和全球众多的粉丝。 GitLab 普通用户使用指南 1.简介 GitLab作为一种仓库管理系统的开源项目，使用Git可以很好地管理项目的代码，从而帮助管理项目。Git给用户提供了创建并使用项目、创建并邀请用户加入项目组等功能。在高级软件工程课程中，Git主要是作为辅助工具来使用。 2.修改密码 在开始使用之前，管理员已经为每个用户注册好了账号，用户登录之后，要先修改密码（登录后直接进入修改密码界面，见图1），密码为八位字符串。 图1 修改密码 修改密码之后，重新登录系统，可以对Git进行下一步的操作。 3.创建项目组 项目在多数的情况下要由项目组员配合完成，因此，用户在使用Git的时候，第一步需要做的就是要创建组。创建项目组之后，将其他项目成员邀请进入该组。创建和邀请的功能由一个组员完成就可，不需要多人重复操作。修改密码之后，会自动退出至登录界面，重新登录之后，进入Git的欢迎界面，见图2. 图2 欢迎界面 若是管理员赋予了该登录用户新建工程和组的权限，那么，在欢迎界面中，就可以看到 普通用户最基本的功能是新建工程、新建组、以及参加公有工程。在新建项目组功能中，点击“New group”，可以进入新建项目组的界面，见图3. 图3 新建组 在图3所示的界面中，依次输入项目组名、详细信息、说明文件（可选），点击“Create Group”就可以完成新建项目组的功能。新建项目组之后，会进入图4所示的界面，界面显示当前只有一个组“GroupForUserGuide”。并且在此也可以点击“New project”，新建工程。创建好项目组后，就要在项目组中添加组员，点击图4中的“Members”选项，进入图5所示的邀请组员界面。 图4 新建组后跳转到首页 点击图5中的“Add members”，就可进入图6所示的界面。在图6中，可以添加组员，并且为组员设置权限。在高级软件工程课程中，组长邀请组员的时候，只需要将组员权限设置成Developer就可。将多个组员邀请进入项目组之后，就可以新建工程了。 小白入门学习web前端，这些干货不能少 web前端怎么样才能入门，首先我们要从什么是初级web前端工程师说起： 按照我的想法，我把前端工程师分为了入门、初级、中级、高级这四个级别， 入门级别指的是了解什么是前端（前端到底是什么其实很多人还是不清楚的），了解基本的html、css和javascript语法（这些语方面的东西网上随便搜一下就有很多很多，基本的语法是整个技术体系最重要的东西了，领先的 Web 技术教程），可以根据设计师的设计图在不考虑兼容性的情况下把页面做出来，了解过一些框架的使用（例如烂大街但是依然牛逼的jQuery、zepto、 bootstrap 等等）。 在经历过入门的阶段，已经了解了前端要做什么，并且把基本的语法学习过了可以独立做一些简单的页面了，那么就前端的学习都是需要不断的学习，学一天停一停相当于白学，学习效果很差，如果你想有人一起学习可以来这个扣裙，首先是132 中间是667最后是127 都是零基础的同学，大家相互鼓励共同努力只是学着玩就不建议来了!!!要继续学习达到初级前端工程师的水平，对于初级的 前端工程师需要了解的就特别多了，需要对整个前端有一个清晰的认识，并且熟练使用各种技术。 初级前端工程师：首先要知道的就是如何处理各种浏览器的兼容处理（比如说在IE浏览器中的createElement有什么不同等等内容），现在基本上每个公司在 招聘的时候都会要求熟练html5, css3, javascript，这个熟练的意思就是信手拈来。 在下面会说初级前端工程师应该具体的学习哪些知识，然后就是要了解各种css 的预处理器和后处理器，还有会使用常见前端的MV*框架（angularjs, backbone，reactjs等等）并知道这些框架的原理，另外就是要熟练使用nodejs，要会使用基于node的各种前端构建工具（grunt，gulp等等），熟练使用github或gitlab，对模块化、组件化、工程化、语义化有一个比较深入的了解，最后要知道如何开发移动端的页面，如何去优化一个页面的性能。 初级web前端工程师的技术体系 1.HTML部分 首先是要掌握一些常用标签的使用和他们的各个属性，这些常用的标签我总结了一下有以下这些： html：页面的根元素。head：页面的头部标签，是所有头部元素的容器。body：页面的主体标签，页面展现的内容就放置在这里面。title：页面的标题。meta：位于文档的头部，提供页面的元信息，包括关键字、描述等等。link：定义文档与外部资源的关系，最常用的用途就是引入样式表。script：脚本标签，可以把 js脚本代码放置在这个标签内，也可以使用这个标签的src属性引入一个外部 标签。style：样式标签，可以把css代码写在这个标签中。 a：超链接，href属性代表要链接到的地方，target属性代表打开方式。img：图像标签，src属性表示图片的位置。form：表单元素，它内部的input、select、textarea等标签都是比较重要的。div：定义文档中的分区或节，可以使用div 来进行页面的布局等操作。另外还有ul、li、p、button、iframe、p、table 等标签也很常用，nav、section、article、header、aside、footer等语义化 标签也需要了解一下。 微服务开发手册 1．开发说明war服务器，无需生成内嵌了所有服务均基于spring boot框架开发。Spring boottomcat● spring的开发。包，并简化了maven配置，能够让开发者快速入手 规范。restful rest规范参考第2节●服务的接口定义需严格符合 同时平台也能够实所有服务都需要在注册服务上注册，否则不能被其他服务所调用。●时监测服务的状态，能够及时预警及调度资源。 所有服务的配置信息统一保存于gitlab上，并通过配置服务获取配置。● 和高级映SQL查询，是个支持普通●对数据库的操作统一采用MyBatis?框架。MyBatis 到mybatismybatis的集成方案，可以很快捷地整合boot射的优秀框架。Spring 也提供了项目中。 ●包名约定：所有包均以. 服务名为父包名，如，后面再跟具体模块名称作为子包名。 ●所有项目基于来开发。项目的管理与构建采用maven，代码统一托管于gitlab仓库。 2．rest api接口规范 架构中，每个网址代表一种资源RESTful风格。在restful接口设计需符合bootspring （resource），所以网址中不能有动词，只能有名词，而且所用的名词往往与数据库的表格名对应。 而客户端要执行某种类型的操作，需要根据http的操作协议来决定。HTTP提供了常用的几种操作，如下表： 对数据库的增删改查操作，应该严格遵守上面定义的五种HTTP 动作。。服务端返回数据格式也均来传递，格式为json对于更新动作，参数通过requestbody 。json为服务端返回数据对象约定： public class UnifyInfo { roperties gitlab使用指南
微服务开发手册
私有 gitlab 使用手册
gitlab
简易使用手册
CE
SCM
编号 密等 日期 作者
Mar. 30, 2016 Roy Hu
版本 Revisio
n
出版日期 Issue Date
修订章节 Section Changed
出版修订原因 Reason for issue
Draft mm-dd-yyyy
All
Draft Initial
备注 Remarks
1 第一章 简介 ............................................................
设备现况 ..............................................................................
2 TORTOISEGIT ............................................................
先到下载 git for Windows 适合的版本安装................................................ 到下载适合的版本安装 .................................................................. 初始化版本库目录 ...................................................................... Commit 提交 ........................................................................... 提交时产生新分支 ...................................................................... 提交的时机 ............................................................................ Stash 储藏 ............................................................................ 切换至某分支/取出某提交 ...............................................................
3 ATLASSIAN SOURCETREE ...................................................
到下载 ................................................................................ 浏览整个专案 ..........................................................................
4 GITLAB CE ..............................................................
登入 .................................................................................. 画面说明 .............................................................................. Groups 专案群组 ....................................................................... TortoiseGit push 推送本地版本库至 GitLab CE 上的新专案 .................................
於 GitLab CE 建立新专案...............................................................GIT提交说明
本地GitLab服务器找回GitLab管理员账户密码的方法
GitLab使用文档-管理员
Gitlab使用手册
测试任务交接说明
Git-简单使用教程(个人独享版)
使用Git开发项目流程说明
容器技术与用户自服务平台建设方案
GitLab 普通用户使用指南
小白入门学习web前端
微服务开发手册