软件三库管理规范-标准化文件发布号：（9456-EUATWK-MWUB-WUNN-INNUL-DDQTY-KII
1目的范围 规定了公司软件开发库、受控库、产品库（以下简称三库）的管理规范。 2参考文献 《软件三库管理制度》 3术语和定义 GitLab：一个仓库管理系统，使用Git作为代码管理工具，并在此基础上搭建起来的web服务。 Jenkins：基于Java开发的一种持续集成平台，用于监控持续重复的工作。 SPM：公司研发部开发的持续集成工具，用于集成软件部署包。 Releaser：公司研发部开发的基于SPM的软件部署包发布工具。 Kiwi TCMS：公司研发部基于开源代码改进的测试用例管理系统，用于测试计划和测试用例的创建和维护、以及测试执行的记录。 4职责 4.1软件三库管理职责 软件开发库由项目组管理，软件受控库由研发部管理，软件产品库由质量部管理。 4.2软件管理员职责 a)具备软件配置管理知识； b)熟悉研制项目的配置管理； c)熟悉公司结构、软件三库管理规定、标识规定和软件配置管理计划。 5管理内容与方法 5.1建立软件三库 5.1.1 开发库 a)开发库代码部分和说明部分基于GitLab建立，按照软件项目分配仓库。 项目组长任仓库Master，负责需求说明的管理、成员管理、问题跟踪、分支Merge、任务分配、Tag标识等工作。 项目组成员任仓库Developer，负责设计和交付说明的管理、问题调查、分支维护等工作。 测试组成员任仓库Reporter，负责测试说明的管理、报告问题、问题回归等工作。 b)开发库部署包部分基于Jenkins和SPM建立，按照软件项目分配仓库。
系统自带authsvr服务进程，和两个子例程，tpsvrinit(),tpsvrdone。 authsvr：客户端调用tpinit进行认证时，由交易TPAPPAUTH回应。 服务端自动调用tpsvrinit,可以在函数中进行数据库连接和处理命令行参数。 结束时tpsvrdone也被自动调用，可以在函数中断开数据库连接。 这两个例程分别在进程开始时和进程将要结束时，被自动调用。 服务端编程指导： 交易内一次只能接收一个请求，发送一个响应。 交易必须以tpretrurn, tpforward结束。 或交易内使用了tpacall,在返回或转发前，要么等待回应，要么使用tpcancel。 tpreturn一旦被调用，控制权就转移到main函数，未进行显示收取的响应会被丢弃，此时客户端会收到错误。 客户端调用tpcall后，若服务端此时对应的tpreturn成功返回，客户端tpcall才能返回。 客户端调用tpacall后，若服务端此时对应的tpreturn成功返回，客户端tpgetrply才能返回。返回的数据，可由客户端从指针*data处取得。 tpforward调用时，程序逻辑应保证之前的处理都正确,响应被收到。被调用后，交易不再等待响应。main函数取得控制权。被请求的另一个交易负责响应原来的请求。不能将请求转发到自身。 tpreturn 的参数： rval: 表明交易是否成功执行。 rcode：是应用自定义的返回值。客户端可通过tpurcode获得tpreturn的rcode值，而不论交易是否成功。 data: 该缓冲区由客户端传递，服务端可以将回应数据写至此地址。也可以进行tprealloc.而不能tpfree. 服务端也可以自行tpalloc一个缓冲区，并返回给缓冲区，但需要自行若管理。如果发送的数据长度大于已分配的，tuxedo会自动扩大缓冲。 len: 用来指示响应缓冲的长。客户端可据此得知数据是否有变化。 如果客户端需要收到一个响应，而tpreturn自身处理时出错，这时tpcall或tpgetrply会失败，客户端应检查tperrno. 此时客户端的data缓冲区没有变化。若交易返回的消息不符客户端要求，则无法判断应用状态，此时原来的缓冲区保持不变。如果交易超时，响应数据不会被发送。 发布与取消交易名： 当一个服务进程被启动后，它会根据配置文件来向公告板上广告自己有交易名。这通常由buildserver命令执行时完成。 tpcall:
1 目的范围 规定了公司软件开发库、受控库、产品库（以下简称三库）的管理规范。 2 参考文献 《软件三库管理制度》 3 术语和定义 GitLab：一个仓库管理系统，使用Git作为代码管理工具，并在此基础上搭建起来的web服务。 Jenkins：基于Java开发的一种持续集成平台，用于监控持续重复的工作。 SPM：公司研发部开发的持续集成工具，用于集成软件部署包。 Releaser：公司研发部开发的基于SPM的软件部署包发布工具。 Kiwi TCMS：公司研发部基于开源代码改进的测试用例管理系统，用于测试计划和测试用例的创建和维护、以及测试执行的记录。 4 职责 4.1软件三库管理职责 软件开发库由项目组管理，软件受控库由研发部管理，软件产品库由质量部管理。 4.2软件管理员职责 a)具备软件配置管理知识； b)熟悉研制项目的配置管理； c)熟悉公司结构、软件三库管理规定、标识规定和软件配置管理计划。 5 管理内容与方法 5.1建立软件三库 5.1.1 开发库 a)开发库代码部分和说明部分基于GitLab建立，按照软件项目分配仓库。 项目组长任仓库Master，负责需求说明的管理、成员管理、问题跟踪、分支Merge、任务分配、Tag标识等工作。 项目组成员任仓库Developer，负责设计和交付说明的管理、问题调查、分支维护等工作。 测试组成员任仓库Reporter，负责测试说明的管理、报告问题、问题回归等工作。 b)开发库部署包部分基于Jenkins和SPM建立，按照软件项目分配仓库。
项目组成员负责维护自动测试脚本和版本生成脚本。 Jenkins管理员（计算机）任库管理员，负责自动检查代码编译结果，执行版本生成脚本将通过检查的工程生成待测软件部署包，执行自动测试脚本验证软件部署包，将通过验证的软件部署包打上标识，放入仓库。 另任库管理员，负责出入库管理、配置项管理等工作。 5.1.2 受控库 a)受控库代码部分基于GitLab建立，按照软件项目分配仓库。 软件经理任仓库Master，负责将通过完整测试的开发版本打上Tag标识，在GitLab 上作为独立稳定的分支，该分支不接受更改，有效受控。 b)受控库部署包部分基于Jenkins和SPM建立，按照软件项目分配仓库。 Jenkins管理员（计算机）任库管理员，负责将打上Tag标识的代码版本生成软件部署包，打上同样的Tag标识，放入仓库。 该部分目录及目录下文件一旦生成，不可删除或更改，有效受控。 c)受控库说明部分存在于公司内部的公共服务器。 另任库管理员，负责出入库管理、配置项管理等工作。 d)受控库测试用例部分基于Kiwi TCMS建立，按照软件项目分配仓库。 项目组长具有测试计划审核权限，测试组长具有测试用例编辑和测试用例审核权限，测试组成员具有测试用例编辑权限。 5.1.3 产品库 产品库存在于公司内部公共服务器，按照软件项目分配仓库。 另任库管理员，利用Releaser工具将通过申请的打上Tag的受控版本生成软件产品包，负责各产品的出入库管理、配置项管理等工作。 5.2制定三库管理规定 5.2.1 内容要求 软件三库管理规定： a)入库控制 相关人填写入库申请，负责人审批，库管理员操作或检查入库，详见三库管理要求（第5.4、5.5、5.6节）。 b)访问控制 各仓库设置权限管理，一般来说，给予库管理员写权限，给予相关人读权限，详见三库管理要求（第5.4、5.5、5.6节）。
规定了公司软件开发库、受控库、产品库（以下简称三库）的管理规范。 1参考文献 《软件三库管理制度》 2术语和定义 GitLab：一个仓库管理系统，使用Git作为代码管理工具，并在此基础上搭建起来的web服务。 Jenkins：基于Java开发的一种持续集成平台，用于监控持续重复的工作。 SPM：公司研发部开发的持续集成工具，用于集成软件部署包。 Releaser：公司研发部开发的基于SPM的软件部署包发布工具。 ￥ Kiwi TCMS：公司研发部基于开源代码改进的测试用例管理系统，用于测试计划和测试用例的创建和维护、以及测试执行的记录。 3职责 3.1软件三库管理职责 软件开发库由项目组管理，软件受控库由研发部管理，软件产品库由质量部管理。 3.2软件管理员职责 a)具备软件配置管理知识； b)熟悉研制项目的配置管理； c)熟悉公司结构、软件三库管理规定、标识规定和软件配置管理计划。 4[ 5管理内容与方法 5.1建立软件三库 开发库 a)开发库代码部分和说明部分基于GitLab建立，按照软件项目分配仓库。 项目组长任仓库Master，负责需求说明的管理、成员管理、问题跟踪、分支Merge、任务分配、Tag标识等工作。 项目组成员任仓库Developer，负责设计和交付说明的管理、问题调查、分支维护等工作。 测试组成员任仓库Reporter，负责测试说明的管理、报告问题、问题回归等工作。 b)开发库部署包部分基于Jenkins和SPM建立，按照软件项目分配仓库。
[ 项目组成员负责维护自动测试脚本和版本生成脚本。 Jenkins管理员（计算机）任库管理员，负责自动检查代码编译结果，执行版本生成脚本将通过检查的工程生成待测软件部署包，执行自动测试脚本验证软件部署包，将通过验证的软件部署包打上标识，放入仓库。 另任库管理员，负责出入库管理、配置项管理等工作。 受控库 a)受控库代码部分基于GitLab建立，按照软件项目分配仓库。 软件经理任仓库Master，负责将通过完整测试的开发版本打上Tag标识，在GitLab 上作为独立稳定的分支，该分支不接受更改，有效受控。 b)受控库部署包部分基于Jenkins和SPM建立，按照软件项目分配仓库。 Jenkins管理员（计算机）任库管理员，负责将打上Tag标识的代码版本生成软件部署包，打上同样的Tag标识，放入仓库。 — 该部分目录及目录下文件一旦生成，不可删除或更改，有效受控。 c)受控库说明部分存在于公司内部的公共服务器。 另任库管理员，负责出入库管理、配置项管理等工作。 d)受控库测试用例部分基于Kiwi TCMS建立，按照软件项目分配仓库。 项目组长具有测试计划审核权限，测试组长具有测试用例编辑和测试用例审核权限，测试组成员具有测试用例编辑权限。 产品库 产品库存在于公司内部公共服务器，按照软件项目分配仓库。 另任库管理员，利用Releaser工具将通过申请的打上Tag的受控版本生成软件产品包，负责各产品的出入库管理、配置项管理等工作。 5.2, 5.3制定三库管理规定 内容要求 软件三库管理规定： a)入库控制 相关人填写入库申请，负责人审批，库管理员操作或检查入库，详见三库管理要求（第、、节）。 b)访问控制
第9章如何用好全局事务 9.1 什么是全局事务 全局事务是由资源管理器管理和协调的事务，可以跨越多个数据库和进程。事务管理器一般使用XA二阶段提交协议与“企业信息系统（EIS）”或数据库进行交互。 也就是当一个事务需要跨越多个数据库时，需要使用全局事务。例如，一个事务中可能更新几个不同的数据库。对数据库的操作发生在系统的各处，但必须全部被提交或回滚。此时，一个数据库对自己内部所做操作的提交不仅依赖本身操作是否成功，还要依赖与全局事务相关的其他数据库的操作是否成功，如果任一数据库的任一操作失败，则参与此事务的所有数据库所做的所有操作都必须回滚。 在一个涉及多个数据库的全局事务中，为保证全局事务的完整性，由交易中间件控制数据库做两阶段提交是必要的。但典型的两阶段提交，对数据库来说事务从开始到结束（提交或回滚）时间相对较长，在事务处理期间数据库使用的资源（如逻辑日志、各种锁），直到事务结束时才会释放。因此，使用典型的两阶段提交相对来说会占用更多的资源，如果网络条件不好，如低速网、网络颠簸频繁，情况会更为严重。 9.2 本地事务的优缺点 本地事务容易使用，但也有明显的缺点：它们不能用于多个事务性资源。例如，使用JDBC连接事务管理的代码不能用于全局的JTA事务中。另一个缺点是局部事务趋向于侵入式的编程模型。 9.3 Tuxedo对事务的控制与管理 当客户端连接到Tuxedo并创建一个全局事务时，TM（Transaction Manager，事务管理器）就会在公告板（BB）里面创建一个事务，由TMS向GTT（Global Transaction Table，全局事务表，里面包含当前事务的状态信息）中插入一个条目，然后分配一个GTRID（Global Transaction Identifier，全局事务标识符）来对该事务进行跟踪。 Tuxedo的事务管理由TMS完成，TMS把各种RM接入到Tuxedo中的分布式计算中来，并对RM中执行的事务进行跟踪和两阶段提交。 Tuxedo对事务的管理工作主要包括创建TMS、创建TLOG、运行时事务的监控和迁
信息安全服务工具列表 15 Troubleshooting Troubleshooting - Sysdig是一个能够让系统管理员和开发人员以前所未有方式洞察其系统行为的监控工具。一款系统调试工具，能够对系统进行故障排查和监控，在系统故障的时候非常实用。 Troubleshooting - SystemTap 是监控和跟踪运行中的Linux 内核的操作的动态方法。 Troubleshooting - Perf 是Linux kernel自带的用来进行软件性能分析的工具。通过它，应用程序可以利用 PMU，tracepoint 和内核中的特殊计数器来进行性能统计。它不但可以分析指定应用程序的性能问题 (per thread)，也可以用来分析内核的性能问题，当然也可以同时分析应用代码和内核，从而全面理解应用程序中的性能瓶颈。 16 服务发现 服务发现- etcd 是一个高可用的 Key/Value 存储系统，主要用于分享配置和服务发现。在分布式系统中，如何管理节点间的状态一直是一个难题，etcd像是专门为集群环境的服务发现和注册而设计，它提供了数据TTL失效、数据改变监视、多值、目录监听、分布式锁原子操作等功能，可以方便的跟踪并管理集群节点的状态。 17 持续集成 持续集成-Go 是一款先进的持续集成和发布管理系统,由ThoughtWorks开发。在Go的帮助下，我们能够以流水线的方式实现各类定期执行任务，而这些操作当中的实例会被称为job。还有它能够利用值流图对整个持续交付流程进行可视化处理。最终生成的图表能帮助我们追踪从提交到部署的整个流程中的各项具体变更。 持续集成-Jenkins，之前叫做Hudson，是基于Java开发的一种持续集成工具，用于监控秩序重复的工作，包括：1,持续的软件版本发布/测试项目 2，监控外部调用执行的工作。 持续集成-GitLab是一个利用 Ruby on Rails 开发的开源应用程序，实现一个自托管的Git项目仓库，可通过Web界面进行访问公开的或者私人项目。能够浏览源代码，管理缺陷和注释。可以管理团队对仓库的访问，它非常易于浏览提交过的版本并提供一个文件历史库。它还提供一个代码片段收集功能可以轻松实现代码复用，便于日后有需要的时候进行查找。
第四章：TUXEDO应用系统的管理 4.1 TUXEDO提供的系统管理工具 当一个TUXEDO应用系统投入运行时，TUXEDO系统管理员要对它进行监控，管理，根据系统的运行情况做相应的参数调整。有时候还要动态修改配置，发布新的服务等等，TUXEDO提供了很丰富的管理工具和管理编程接口。可以很方便的完成这些管理任务。下面对管理工具和管理编程接口分别进行介绍。 TUXEDO提供以下管理工具 1．基于WEB的图形化管理工具：用普通的WEB 浏览器比如Netscape或Microsoft 的Explorer可以从Internet/Intranet 的任意一个节点来运行该图形界面管理工具。对 系统进行管理配置。 2. 基于字符界面的管理工具：TUXEDO提供TMADMIN，DMADMIN等命令行管理工具。 TUXEDO提供以下管理编程接口 1.MIB编程接口：TUXEDO 提供C 语言的管理API ，用户能够用此编写出适合自己特殊需 求的管理工具 2.通过SNMP与其他管理工具（HP OpenView 等）互联， TUXEDO 的关联产品 BEA MANAGER 通过网络管理协议 SNMP和TUXEDO 的管理信息库 MIB 可以把TUXEDO 对应用程序的管理集成到一般的网络、数据库系统管理工具中，比如 OpenView, NetView 等。 TUXEDO应用系统的管理任务 通过以上的管理工具，TUXEDO可以有效地管理消息流程和服务请求，启动和停止服务进程，根据变化的负荷复制服务进程，动态地广播、撤消服务进程中的服务。并且可以在客户不用退出执行的情况下，动态的增加新的服务器、服务器组、服务器以及服务。利用命令行或图形管理界面TUXEDO还可以动态的进行负载平衡，数据依赖路由、网络用户的管理、队列的管理、存取资源管理器以及系统的启动、重启和恢复。
第1页共9 页 1 目的范围 规定了公司软件开发库、受控库、产品库（以下简称三库）的管理规范。 2 参考文献 《软件三库管理制度》 3 术语和定义 GitLab：一个仓库管理系统，使用Git作为代码管理工具，并在此基础上搭建起来的web服务。 Jenkins：基于Java开发的一种持续集成平台，用于监控持续重复的工作。 SPM：公司研发部开发的持续集成工具，用于集成软件部署包。 Releaser：公司研发部开发的基于SPM的软件部署包发布工具。 Kiwi TCMS：公司研发部基于开源代码改进的测试用例管理系统，用于测试计划和测试用例的创建和维护、以及测试执行的记录。 4 职责 4.1软件三库管理职责 软件开发库由项目组管理，软件受控库由研发部管理，软件产品库由质量部管理。 4.2软件管理员职责 a)具备软件配置管理知识； b)熟悉研制项目的配置管理； c)熟悉公司结构、软件三库管理规定、标识规定和软件配置管理计划。 5 管理内容与方法 5.1建立软件三库 5.1.1 开发库 a)开发库代码部分和说明部分基于GitLab建立，按照软件项目分配仓库。 项目组长任仓库Master，负责需求说明的管理、成员管理、问题跟踪、分支Merge、任务分配、Tag标识等工作。 项目组成员任仓库Developer，负责设计和交付说明的管理、问题调查、分支维护等工作。
第2页共9 页 b)开发库部署包部分基于Jenkins和SPM建立，按照软件项目分配仓库。 项目组成员负责维护自动测试脚本和版本生成脚本。 Jenkins管理员（计算机）任库管理员，负责自动检查代码编译结果，执行版本生成脚本将通过检查的工程生成待测软件部署包，执行自动测试脚本验证软件部署包，将通过验证的软件部署包打上标识，放入仓库。 另任库管理员，负责出入库管理、配置项管理等工作。 5.1.2 受控库 a)受控库代码部分基于GitLab建立，按照软件项目分配仓库。 软件经理任仓库Master，负责将通过完整测试的开发版本打上Tag标识，在GitLab 上作为独立稳定的分支，该分支不接受更改，有效受控。 b)受控库部署包部分基于Jenkins和SPM建立，按照软件项目分配仓库。 Jenkins管理员（计算机）任库管理员，负责将打上Tag标识的代码版本生成软件部署包，打上同样的Tag标识，放入仓库。 该部分目录及目录下文件一旦生成，不可删除或更改，有效受控。 c)受控库说明部分存在于公司内部的公共服务器。 另任库管理员，负责出入库管理、配置项管理等工作。 d)受控库测试用例部分基于Kiwi TCMS建立，按照软件项目分配仓库。 项目组长具有测试计划审核权限，测试组长具有测试用例编辑和测试用例审核权限，测试组成员具有测试用例编辑权限。 5.1.3 产品库 产品库存在于公司内部公共服务器，按照软件项目分配仓库。 另任库管理员，利用Releaser工具将通过申请的打上Tag的受控版本生成软件产品包，负责各产品的出入库管理、配置项管理等工作。 5.2制定三库管理规定 5.2.1 内容要求 软件三库管理规定： a)入库控制 相关人填写入库申请，负责人审批，库管理员操作或检查入库，详见三库管理要求（第5.4、5.5、5.6节）。
高级运维工程师工作的岗位职责 高级运维工程师需要负责日常系统维护，及监控，提供iT软硬件方面的服务和支持，保证系统的稳定。下面是xx 整理的高级运维工程师工作的岗位职责。 高级运维工程师工作的岗位职责1 职责: 1. 负责各区块链节点的搭建部署。 2. 负责运维开发体系规划，架构设计 3. 负责基础设施运维平台系统设计和开发，(包括基础设施管理、构建发布、配置管理、监控告警等系统); 4. 推进自动化运维体系建设，提升运维工作效率。 5. 提供高效区块链节点服务。 任职要求： 1. 计算机相关专业，3-5年以上的工作经验。(大型互联网企业背景优先); 2. 有实际运维工作经验，熟悉Saltstack/Puppet/confd/ansible等自动化运维、配置管理工具; 3. 掌握shell、python脚本语言，并主导或参与过自动化运维平台项目的开发;
4. 了解区块链(btc,eth,eos等)技术，原理，编译和搭建部署 5. 有亚马逊平台使用经验。 6. 有高度网络安全防范意识。 7. 有较强的团队协作能力，学习能力，沟通协调能力，并能自我驱动. 高级运维工程师工作的岗位职责2 职责： 1、负责系统维护、系统日常监控; 2、完成公司软件产品部署、升级、测试、备份及恢复，配合现场人员进行系统调试; 3、收集客户需求，处理客户协调工作; 4、提供内部技术支持、培训及客户培训工作。 任职资格; 1、熟练掌握nginx、tomcat、myspl等服务配置，能够熟练操作数据库，懂开发语言者优先;精通linux各类命令操作更加; 2、熟悉软件工程，相关集成产品，精通安装环境配置，系统调试，安装过程; 3、有较强的独立分析问题和解决问题的能力，在任务繁杂的情况下，有效梳理并合理安排任务优先; 4、有责任感和团队合作精神，自学能力强，能够承受
Tuxedo基本参数配置说明 2008-12-08 17:23:49 标签：Tuxedo 一、Tuxedo基本命令 #1.设置环境变量TUXDIR,APPDIR,TUXCONFIG，LANG(跟OS相关),LD_LIBRARY_PATH(跟OS相关) #2.编译ubb文本生成二进制配置文件：tmloadcf ?Cy ubbconfig #3.所有机器上运行tlisten,具体见文档中NETWORK一节 #4.启动tmboot ?Cy #5.关闭tmshutdown ?Cy 参数： -A 在所有机器上启动/关闭管理的Server进程 -M 只在MASTER机器上启动/关闭管理的Server进程 -i srvid 启动/关闭某个server id指定的Server进程 -g grpname 启动/关闭某个server group名字指定的Server Group -S 启动/关闭所有应用服务器（LMID） -s server-name 启动/关闭某个server名字指定的Server进程 -l lmid option 在指定的机器上启动/关闭所有TMS进程和应用服务器（LMID） -T grpname 启动/关闭指定的server group中所有的TMS进程 -B lmid 在指定的机器上启动/关闭BBL进程 -e command 指定一个程序可以当在MASTER机器上启动任何一个进程失败时执行 -c 计算出当前UBB配置的Tuxedo启动最少要占用的系统IPC资源 #用tmunloadcf > generated.ubb 可以得出目前配置得UBB文件所有得参数值（没有设置的有缺省值） #用tmloadcf ?Cc或tmboot ?Cc可以计算出当前UBB配置的Tuxedo启动最少要占用的系统IPC资源。 二、UBB文件配置说明 UBB配置文件分成*RESOURCES,*GROUP,*SERVER,*SERVICE,*NETWORK等若干节。DEFAULT表示该节中所有对象共有的缺省属性。 *RESOURCES #RESOUCES节提供整个系统的基本参数。 IPCKEY 55555 （32767-262143） #进行IPC通讯的key值 DOMAINID unicom #DOMAIN的ID值 MASTER unicom1,unicom2 #指定DOMAIN中的管理主机为unicom1,运行过程中unicom1若出现问题，管理主机切换至unicom2 MAXACCESSERS 1000
代码管理工具GitLab 可视化界面在 windows 安装教程 --作者：Able 1.Windows下TortoiseGit over Putty or Openssh提交项目到GitLab（可视化工具）：（安装教程按照1进行） 具体安装教程： Windows下TortoiseGit over Putty or Openssh提交项目到GitLab Gitlab默认的配置推荐使用shell命令行与server端进行交互,作为搞SCM的表示无压力,但是作为开发人员还是比较适应windows的GUI图形管理,方便他们将注意力集中到代码编写上,所以今天刚好接着昨天给大家介绍一下使用windows下的git client工具实现将本地代码提交到远程服务器. 解决方案： 环境部署 操作系统Windows7 x64 Sp1 TortoiseGit TortoiseGit-1.8.11.0-64bit.msi Git Git-1.9.4-preview20140815.exe Putty PuTTY 0.63 OpenSSH owned by Git 下载地址: https://www.doczj.com/doc/eb15753652.html,/QaaLGsd23BsWL(访问密码96d7) 注: 此处下载地址中的安装包都为64位版本,32位请另行下载. 一.部署前的准备工作 安装TortoiseGit,Git,Putty,默认下一步安装即可,其中Git为Git client环境安装包,确保w indows包含git环境. 二.配置PuTTY authentication agent 在安装TortoiseGit后,可以选择使用OpenSSH客户端还是使用Putty客户端,如果使用的是默认的Putty客户端,由于TortoiseGit GUI连接不支持server端自定义端口配置,若GitLab 使用的SSH端口为自定义端口,则需要使用PuTTY的authentication agent去做一个本地的端口转发. 1.首先使用TortoiseGit自带的Puttygen创建本地的公/私钥对
by Charles Wu 最近本人在经历了GitLab的一番折磨后终于搭建好了源码管理服务器GitLab，走了很多弯路被折磨了很久，为了总结此次的经验以及让广
PS：如何打开终端？？似乎新安装的ubuntu在启动器里面没有快捷键。。。直接使用：CTRL+ALT+T 2.然后使用这个命令下载文件
在Ubuntu下双击该文件安装时提示不是文件所有者。先在文件右击鼠标->属性->权限，看看最下边“执行”是否让选择，如果让选择，选择上后可以直接安装，不让选择就需要进行下面步骤。 1.更改文件所有者，在控制台中输入： sudo chown -R username ./filename（R一定要大写） a）-R ：递归文件夹内部的所有文件及文件夹 b）username：目标所有者名称（你登录系统的用户名）
c）filename：文件或文件夹名称 （你要修改的文件名） 1.更改文件权限，在控制台中输入： chmod +x ./XXX.run （XXX是指文件的名字） PS上门的步骤一般不需要执行，除非文件所有者和允许执行没有打勾3.安装.run文件 控制台输入： sudo ./XXX.run，或者双击文件运行，这里切记切记 ./
这里是填写你的服务器的域名或者ip地址，所以记得把你的git服务器设置为固定ip 一路Next就会自动安装了。。。只要步骤对还是很简单的 安装完后会自动启用管理界面，这个使用你最好把这个管理器做个快捷方式，我当时就是没做，关闭后就找不到了也懒得找，我后面都是
六、接着你就可以使用了 1.登录gitlab 创建用户组、项目等 2.使用git客户端生产你的SSHKey并且导入到gitlab
1 tmloadcf 检查UBBCONFIG文件的内容及格式 将文本格式的UBBCONFIG文件编译生成二进制文件 必须在主机上运行 格式 tmloadcf [-n] [-y] [-c] [-b blocks] {UBBCONFIG_file | -} 参数 -c 计算最小的IPC需求 -n 仅仅进行UBBCONFIG文件的内容检查，不生成二进制文件 -y 覆盖已有的二进制文件之前不提示 -b blocks 如果环境变量TUXCONFIG所指的文件存放在一个裸设备上，建议使用该参数；如果该文件存放在文件系统上，则不需要 2 tmunloadcf 将二进制TUXCONFIG文件反编译为文本格式 3 tmipcrm 清除本机上的IPC资源 自动根据TUXCONFIG_file参数查找相应的IPC资源 一般在Tuxedo非正常停止的情况下用来清理残留IPC资源 格式 tmipcrm [-y] [-n] [TUXCONFIG_file] 参数 -y 对命令运行过程中的询问回答y -n 不清除IPC资源，只是列出IPC资源 TUXCONFIG_file Tuxedo的配置文件。如果不指定，则使用环境变量TUXCONFIG 4 tmboot 启动Tuxedo 格式 tmboot [-l lmid] [-g grpname] [-i srvid] [-s aout] [-o sequence] [-S] [-A] [-b] [-B lmid] [-T grpname] [-e command] [-w] [-y] [-g] [-n] [-c] [-M] [-d1] 参数 -l lmid 启动所有绑定到这个逻辑主机的服务，包括应用Server、TMS、Gateway等等 -g grpname 启动grpname包含的所有服务，包括应用Server、TMS等 -i srvid 启动所有SRVID为srvid的服务 -s aout 启动Server名字为aout的服务，也可以用来启动TMS、Gateway等服务。通常和-g选项联合使用 -o sequence 启动SERVERS段中SEQUENCE参数为sequence的服务 -S 启动SERVERS段中的所有Server -A 启动管理Server，例如DBBL、BBL、BRIDGE等 -b 从BACKUP主机上启动服务 -B lmid 启动逻辑主机lmid上的BBL服务
1.日志检查清理。检查Tuxedo日志，用vi命令查看日志文件内容，检查有无Tuxedo系统出错记录；检查有无服务异常错误记录；检查有无服务被重起记录；对发现的异常记录进行分析；若无异常情况清除无用的历史日志。 2. 服务器运行情况。检查Tuxedo系统和应用的服务器的运行情况，用“ps －ｅｌｆ｜ｇｒｅｐｓｅｒｖｅｒ名”查看进程相关信息，如运行时间、占用内存大小等；用ｔｍａｄｍｉｎ命令检查看服务器运行情况，执行ｐｓｒ监控服务器运行情况，查看处理的请求数目、忙闲程度。 3. ｓｅｒｖｉｃｅ运行情况。检查ｓｅｒｖｉｃｅ运行情况，用ｔｍａｄｍｉｎ命令中的ｐｓｃ命令查看Ｔｕｘｅｄｏ各ｓｅｒｖｉｃｅ的运行情况和处理的交易数。 4. 队列使用情况。检查Ｔｕｘｅｄｏ队列的使用情况，用ｔｍａｄｍｉｎ命令中的ｐｑ命令查看Ｔｕｘｅｄｏ各ｓｅｒｖｅｒ队列的使用情况，主要查看交易高峰期队列中消息的增加情况，确定是否存在阻塞现象，是否需要对服务数进行调整。 5. 客户机连接情况。检查ＴｕｘｅｄｏＣｌｉｅｎｔ的连接情况，用ｔｍａｄｍｉｎ命令中的ｐｃｌｔ命令查看Ｔｕｘｅｄｏ各客户机的连接情况，检查ＭＡＸＣＬＩＥＮＴ参数是否足够，Ｌｉｃｅｎｃｅ数是否满足并发要求。 6 .配置参数配置。检查Ｔｕｘｅｄｏｕｂｂｃｏｎｆｉｇ文件和ｄｍｃｏｎｆｉｇ文件，根据以上各项检查结果，查看Ｔｕｘｅｄｏ配置文件是否需要调整优化，以使中间件平台良好运行，保存配置文件并归档备案。 7. 系统核心参数配置。检查操作系统核心参数配置是否满足目前应用系统规模要求，是否需要调整，根据具体使用的操作系统提供的命令查看核心参数。 8. tmunloadcf 可以导出ubb 文件, tmloadcf 加载ubb 文件 9. tmboot 启动, tmshutdown 关闭, 当然还有很多参数比如-y -i -s 等
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)
Tuxedo服务出现拥堵后应急处理 步骤1：检查是否有锁或者大消耗的sql 查看数据库上是否有锁或者消耗资源比较大的sql语句。如果有及时通知DBA做相应处理。处理过后，用pq命令查看队列是否有下降。如果没有大的改善，就进入下面步骤。 步骤2：清除堵的队列 据经验来看这个方法是目前维护生产系统代价最小又行之有效的方法，已经写好相应的维护的脚本。出现服务堵塞时，先执行pq命令查看堵塞的队列，效果如下： 每1秒运行1次，按任意键退出! tmadmin - Copyright (c) 2007-2008 Oracle. Portions * Copyright 1986-1997 RSA Data Security, Inc. All Rights Reserved. Distributed under license by Oracle. Tuxedo is a registered trademark. qcscrm1l1serve qcscrm4l1_2 9 100 2 0.3 ngbss tamcbs1l2serve tamcbs4l2 5 100 2 0.3 ngbss tamcbs1l1serve tamcbs4l1 9 100 2 0.5 ngbss tcscrm1l1serve tcscrm1l1 9 100 2 1.9 ngbss qcscrm1l2serve qcscrm3l2 9 100 2 2.0 ngbss qcscrm1l2serve qcscrm1l2 9 150 3 1.7 ngbss tcscrm1l1serve tcscrm4l1 9 200 4 1.5 ngbss tcscrm1l1serve tcscrm3l1 9 200 15 1.6 ngbss TMS_ORA GRPCCCRM2_+ 5 300 15 0.5 ngbss --------- ------------------- --------- -------- -------- ------- > Prog Name Queue Name # Serve Wk Queued # Queued Ave. Len Machine 以上图为例，服务tcscrm1l1server有点堵塞，可以执行维护脚本quick.sh(在每台tuxedo 应用用户下都有)。执行脚本提示如下： 1---全停,tmshutdown -y 2---全启,tmboot -y 3---单停某个服务，tmshutdow -s * 4---单启某个服务，tmboot -s * 5---单停某个服务组，tmshutdow -g * 6---单启某个服务组，tmboot -g * 7---单停某个组下的某个服务，tmshutdow -g 组名 -s 服务名 8---单启某个组下的某个服务，tmboot -g 组名 -s 服务名 9---紧急停全部服务，强行释放所有资源tmipcrm -y a---重启拥堵的队列psr -q 队列名：
SYWD-006-2016软件三库管理制度 1 目的范围 规定了公司软件开发库、受控库、产品库（以下简称三库）的管理规范。 2 参考文献 《软件三库管理制度》 3 术语和定义 GitLab：一个仓库管理系统，使用Git作为代码管理工具，并在此基础上搭建起来的web服务。 Jenkins：基于Java开发的一种持续集成平台，用于监控持续重复的工作。 SPM：公司研发部开发的持续集成工具，用于集成软件部署包。 Releaser：公司研发部开发的基于SPM的软件部署包发布工具。 Kiwi TCMS：公司研发部基于开源代码改进的测试用例管理系统，用于测试计划和测试用例的创建和维护、以及测试执行的记录。 4 职责 4.1软件三库管理职责 软件开发库由项目组管理，软件受控库由研发部管理，软件产品库由质量部管理。 4.2软件管理员职责 a)具备软件配置管理知识； b)熟悉研制项目的配置管理； c)熟悉公司结构、软件三库管理规定、标识规定和软件配置管理计划。 5 管理内容与方法 5.1建立软件三库 5.1.1 开发库 a)开发库代码部分和说明部分基于GitLab建立，按照软件项目分配仓库。 项目组长任仓库Master，负责需求说明的管理、成员管理、问题跟踪、分支Merge、任务分配、Tag标识等工作。 项目组成员任仓库Developer，负责设计和交付说明的管理、问题调查、分支维护等工作。 测试组成员任仓库Reporter，负责测试说明的管理、报告问题、问题回归等工作。 b)开发库部署包部分基于Jenkins和SPM建立，按照软件项目分配仓库。
项目组成员负责维护自动测试脚本和版本生成脚本。 Jenkins管理员（计算机）任库管理员，负责自动检查代码编译结果，执行版本生成脚本将通过检查的工程生成待测软件部署包，执行自动测试脚本验证软件部署包，将通过验证的软件部署包打上标识，放入仓库。 另任库管理员，负责出入库管理、配置项管理等工作。 5.1.2 受控库 a)受控库代码部分基于GitLab建立，按照软件项目分配仓库。 软件经理任仓库Master，负责将通过完整测试的开发版本打上Tag标识，在GitLab 上作为独立稳定的分支，该分支不接受更改，有效受控。 b)受控库部署包部分基于Jenkins和SPM建立，按照软件项目分配仓库。 Jenkins管理员（计算机）任库管理员，负责将打上Tag标识的代码版本生成软件部署包，打上同样的Tag标识，放入仓库。 该部分目录及目录下文件一旦生成，不可删除或更改，有效受控。 c)受控库说明部分存在于公司内部的公共服务器。 另任库管理员，负责出入库管理、配置项管理等工作。 d)受控库测试用例部分基于Kiwi TCMS建立，按照软件项目分配仓库。 项目组长具有测试计划审核权限，测试组长具有测试用例编辑和测试用例审核权限，测试组成员具有测试用例编辑权限。 5.1.3 产品库 产品库存在于公司内部公共服务器，按照软件项目分配仓库。 另任库管理员，利用Releaser工具将通过申请的打上Tag的受控版本生成软件产品包，负责各产品的出入库管理、配置项管理等工作。 5.2制定三库管理规定 5.2.1 内容要求 软件三库管理规定： a)入库控制 相关人填写入库申请，负责人审批，库管理员操作或检查入库，详见三库管理要求（第5.4、5.5、5.6节）。 b)访问控制 各仓库设置权限管理，一般来说，给予库管理员写权限，给予相关人读权限，详见三库管理要求（第5.4、5.5、5.6节）。
基于git、gitlab源码管理解决方案 武汉交易通信息技术有限公司 2017年7月6日
目录 基于git、gitlab源码管理解决方案 (1) 1宗述 (3) 1.1适用范围 (3) 1.2术语解释 (3) 1.3 gitlab简介 (3) 1.4目标以及解决的问题 (3) 1.5应用背景 (3) 2 源码管理需求和问题分析 (4) 2.1项目源码权限控制 (4) 2.2项目源码版本备份与安全 (4) 2.3项目的进度跟踪 (4) 3 基于gitlab解决方案 (5) 3.1 gitlab项目访问级别控制 (5) 3.2 gitlab项目版本库备份 (7) 3.3 gitlab项目版本库管理 (8)
1 宗述 1.1适用范围 本文档适用于产品实施部源码管理域 1.2术语解释 Push: 推送 Pull：拉取 Commit：提交 Clone：克隆 1.3 gitlab简介 gitlab是开源的源码协作软件。使用细粒度访问控制管理git仓库以达到确保你的源码安全。可执行源码检查和提高源码合并请求。每一个项目都有各自的问题跟踪日志。全球超过10万个组织在使用，gitlab是管理git仓库的最流行的软件之一。 1.4目标以及解决的问题 目标： (1)项目访问级别设置。 (2)项目管理和跟踪。 (3)用户访问权限设置。 解决的问题 (1)项目备份繁琐。 (2)版本差异对比繁琐。 (3)版本回退困难。 1.5应用背景 (1)实施项目众多。全国各地的MIS项目、POS项目众多，需要对各个项目 源码、释放包进行备份。采用传统的FTP方式备份源码，随着时间的推 移，源码数量越来越庞大，从最新版本回归到历史版本，需要进行手工