Jenkins 配置用户权限 + Tomcat 发布
前言
部署到jenkins上才是入门第一步，为了权限配置踩了一天坑，先总结下来留存。并分享出来帮助后面的兄弟
配置用户权限
系统设置-Configure Global Security-第一项
红色圈着地方就是设置权限需要选择的地方。
注意：这里有坑,如果不添加用户，直接选择复选框的权限进行保存，就会出现如下异常。
下面会介绍如何跳出这个坑，接着上面的说
各种权限如下(在配置页面将鼠标放到该权限上即可查看帮助)：
其中有一些比较特别的权限：
最大的权限是Overall的Administer，拥有该权限可以干任何事情。
最基本的权限是Overall的Read，用户必须赋予阅读的权限，不然什么都看不到。
Job的Discover权限是一个奇葩的权限，帮助说Discover比Read的级别更低。如果匿名用户(没有访问job的权限)直接访问一个Job的Url将重定向到登陆页面。(经测试，这个权限应该是被废弃了。)
Credentials（证书）权限
创建/删除/ManageDomains/更新视图
ps：如果有个用户被赋予了Overall的Read，并没有被赋予Job的Read权限，那么该用户就无法访问job。原因：没有权限。
其他都是一些基本的权限，大家根据自己的需求选择。
上面说没有添加用户，直接选择权限并保存会出现，访问拒绝问题。解决方式有2种
方式1
修改权限F:\jenkins.2.6.0.3\config.xml
然后重启jenkins。
注意：重启jenkins方式需要单独下载jenkins-cli.jar
路径：系统管理-Jenkins CLI
方式2
恢复默认设置
直接删除F:\jenkins.2.6.0.3\config.xml 中的这一串
class="hudson.security.FullControlOnceLoggedInAuthorizationStrategy"> 方式3配置管理员权限 这种方法适用于已经存在一堆的权限，重新配置麻烦。 在 复制代码 改完之后记得保存额，然后重启Jenkins。 最后给大家说说在配置文件里面怎么辨别使用是哪种权限控制模式 hudson.security.FullControlOnceLoggedInAuthorizationStrategy 登录用户可以做任何事hudson.security.ProjectMatrixAuthorizationStrategy 项目矩阵授权策略 hudson.security.GlobalMatrixAuthorizationStrategy 安全矩阵 hudson.security.LegacyAuthorizationStrategy 遗留模式 建议配置到tomcat，省时省力，还不用担心配置文件改错，无法重启jenkins的尴尬。 发布到Tomcat 方式： 1.下载Tomcat ：https://www.doczj.com/doc/e016070672.html,/download下载 解压apache-tomcat-8.0.35。 2.找到jenkens 根目录中jenkins.war 包，拷贝到apache-tomcat-8.0.35/webapps 中，重启tomcat 注意：如果首次没有安装到tomcat中，再次安装到tomcat中会出现8080端口被占用情况的，需要手动修改端口。 3.修改tomcat端口，\apache-tomcat-8.0.35\conf\server.xml 第68行 connectionTimeout="20000" redirectPort="8443" /> 更改端口，重启tomcat 4.tomcat重启方式 apache-tomcat-8.0.35\bin\startup.bat 关闭shutdown.bat 总结 Jenkins学习不能一步到位，刚接触很多坑。会牵扯到其他语言或者服务器相关知识点，比方说tomcat，myeclipse，shell脚本，gradle 脚本，groovy脚本。幸好有前人已经填了好多坑。 引用 添加用户和管理权限https://www.doczj.com/doc/e016070672.html,/achang21/article/details/48711583 软件配置管理过程指导说明书 目录 1 前言 (2) 1.1 目的 (2) 1.2 适用范围 (2) 1.3 术语名词解释 (2) 2 角色和职责说明 (3) 3 输入 (4) 4 入口准则 (4) 5 配置管理实施 (4) 5.1 配置库结构 (4) 5.1.1 配置库 (4) 5.1.2 配置管理库系统 (6) 5.2 配置管理流程 (6) 5.2.1 配置管理流程图 (6) 5.2.2 配置变更流程图 (7) 5.3 配置标识 (8) 5.3.1 配置库划分 (8) 5.3.2 配置库结构 (8) 5.3.3 配置项命名 (11) 5.3.4 版本编号规范 (11) 5.4 配置管理活动 (12) 5.4.1 制定配置管理计划 (12) 5.4.2 建立配置库 (12) 5.4.3 建立配置项 (12) 5.4.4 基线建立及发布过程 (12) 5.4.5 配置变更 (13) 5.4.6 配置审计 (15) 5.4.7 备份 (16) 6 输出 (16) 7 出口准则 (16) 8 本过程裁剪规定 (16) 1 前言 1.1 目的 用于描述配置管理作用和过程，规范配置管理的实施过程、活动和操作。 1.2 适用范围 适用于在软件生命周期中对各类软件项目的配置管理活动。 1.3 术语名词解释 CCB：Configuration Control Board，配置管理委员会，每个项目组需要建立项目级的CCB作为变更控制权威。CCB由质量工程师、项目经理、测试经理、配置管理员构成，有时也可以包括客户代表、上级质量部门主管。CCB组长可以是质量工程师或质量部领导，但不能是项目经理。 软件配置项：是指软件工程过程中所生产或使用的任何元素，或者是纳入软件产品的元素。它可以是说明书、计算机程序、数据结构或者开发软件产品所使用的工具等，包括：项目文档，源代码，执行程序，相关设备及资料。 软件配置管理：对软件配置项的管理称为软件配置管理。软件配置管理的目的是建立和维护软件项目整个生命周期中工作产品的完整性和可追溯性。 软件工作产品：由定义、维护和使用一个软件过程所产生的任何人工制品，包括过程描述、计划、规程、计算机程序和相关文档，无论是否打算将它们交给客户或最终用户。 软件产品：可交付给客户或最终用户的软件工作产品的子集称作软件产品 基线：基线，是开发过程中标识出的里程碑所交付的一个或多个配置项，也即指一个（或一组）配置项在项目生命周期的不同时间点上通过正式评审而进入正式受控的一种状态它有如下特征：（1）已经过正式的评审和批准；（2）作为项目发展和产品升级的基础。（3）基线变更必须经过CCB审批。 变更控制：对配置项的更改进行评价、协调、认可或不认可以及执行更改的过程。 版本发布：指从项目的配置库中将需交付给客户的所有配置项组装成一个完整的软件产品。即交付给客户的一个包括可执行程序和文档的发布基线称为发布（release）。 配置审计：可以分为物理审计和功能审计。物理审计审查配置项的外在特征的正确性与一致性，主要考查软件受控库的结构、内容及其它相关信息，以验证基线和描述它的文档的一致性；功能审计审查配置项内容的正确性与一致性，主要考核配置项在实现功能上的一致性，功能审计主要通过评审和测试报告体现。 物理审计的内容包括： ? 确认配置项标识的正确性； ? 确认已受控配置项的更改是受到控制的； ? 验证配置库内容与相应记录之间的一致性； ? 验证配置管理活动与相应记录之间的一致性； ? 验证配置管理工作是否符合适用的标准和规程； ? 验证配置管理系统与系统备份的有效性、一致性等。 功能审计的内容包括： ? 验证当前基线所含配置项对前一基线所含配置项的追溯性； ? 确认当前基线所含配置项均正确反映了项目需求； ? 评估基线的完整性； ? 验证当前基线和各基线间所含配置项的一致性； 验证配置库内容的完备性和正确性等。 软件开发项目配置管理工具的选择 通过软件配置管理，将对软件系统中的多重版本实施系统的管理；全面记载系统开发的历史过程，包括为什么修改，谁作了修改，修改了什么；管理和追踪开发过程中危害软件质量以及影响开发周期的缺陷和变化。并对开发过程进行有效地管理和控制，完整、明确地记载开发过程中的历史变更，形成规范化的文档，不仅使日后的维护和升级得到保证，而且更重要的是，这还会保护宝贵的代码资源，积累软件财富，提高软件重用率，加快投资回报…… 每一个软件项目，无论是工程类项目，还是产品类项目，都必须经历需求分析、系统设计、编码实现、集成测试、部署、交付、维护和支持的过程。在这个过程中，将生成各种各样不同的工件，包括文档、源程序、可执行代码、支持库。更可怕的是，频繁出现的变更是不可避免的，因此面向如此庞大且不断变动的信息集，如何使其有序、高效地存放、查找和利用就成为了一个突出的问题。 针对这一问题，最早的开发人员尝试过的解决办法是通过手工来实现： 1)文档：每次修改时都另存为一个新的文件，然后通过文件名进行区分，例如"XXX 软件需求说明书V1.0，XXX软件需求说明书V1.1，XXX 软件需求说明书V2.0."，并且在文件中注明每次版本变化的内容； 2) 源代码：每次要修改时就将整个工程目录复制一份，将原来的文件夹进行改名，例如"XX 项目V1.0、XX 项目1.01、."，然后在新的目录中进行修改； 但是这种方法，不仅十分繁琐，容易出错，而且会带来大量的垃圾数据。如果是团队协同开发或者是项目规模较大时，还是会造成很大的混乱。很显然，这样简陋的方法是无法应对这一问题的。后来，有人尝试从制造工业领域引入了"配置管理"这一概念，通过不懈的研究与实践，最终形成了一套管理办法和活动原则，这也就是软件配置管理。 通过软件配置管理，将对软件系统中的多重版本实施系统的管理；全面记载系统开发的历史过程，包括为什么修改，谁作了修改，修改了什么；管理和追踪开发过程中危害软件质量以及影响开发周期的缺陷和变化。并对开发过程进行有效地管理和控制，完整、明确地记载开发过程中的历史变更，形成规范化的文档，不仅使日后的维护和升级得到保证，而且更重要的是，这还会保护宝贵的代码资源，积累软件财富，提高软件重用率，加快投资回报。 常见的配置管理工具 正如前面所述，由于软件配置管理过程十分繁杂，管理对象错综复杂，如果是采用人工的办法不仅费时费力，还容易出错，产生大量的废品。因此，引入一些自动化工具是十分有裨益的，这也是做好配置管理的必要条件。 正是因为如此，市场上出现了大量的自动化配置管理工具，这些工具的实现原理与基本机制 Jenkins简单使用 目录 关于项目创建 (2) 关于自动部署到容器 (5) 利用Jenkins提供的deploy plugin自动部署 (5) 利用tomcat-maven-plugin自动部署 (6) 关于把WEB项目打成jar包自动部署 (8) 关于项目创建 点击首页的“创建一个新任务”。 输入项目名称，并选择Maven项目（因我们的项目都是Maven项目，所以此处选此项） 点击“OK”，会进入配置页面。 下面只讲到了部分的配置，如果没有特殊需求其它配置保持默认即可。 首先是“丢弃旧的构建”选项，如若勾选此选线可以看到如图界面。 “丢弃旧的构建”主要是用来配置构建历史保存几个版本，或者说是保存多少时间。 “源码管理”选项中配置对应的SCM，我们用的是SVN，所以此处选择“Subversion”，并填入仓库的Url，如图： 如果没有按照“关于配置”配置Maven相关参数，配置页面中的build项处会显示如图错误： “构建触发器”选项用来配置什么时候会进行构建项目。 Build whenever a SNAPSHOT dependency is built:当此项目所依赖的项目在jenkins中被构建Build after other projects are built:在某个项目被构建后，构建此项目 Build periodically:按照指定的时间间隔进行自动构建，不管代码有没有变更。 Poll SCM:按照指定的时间间隔对SCM进行检测，如果代码库有更新则拉取后进行构建。 如图： “pre steps”：build命令之前执行的操作。可以写脚本。 “build”：build命令相关配置。Root POM：项目中pom.xml所在的路径，此路径是相对于workspace的相对路径。Goals and options：可以填写，build命令后跟的参数，如：clean install （先clean在install），clean install -Dmaven.test.skip=true（清除以前的包，重新打包，并跳过测试） “post steps”：build命令之后执行的操作。同pre steps。同样可以写脚本。 注：脚本中可以引用的变量，参见官方文档： https://https://www.doczj.com/doc/e016070672.html,/display/JENKINS/Building+a+software+project 最后点击“保存”。 可以点击如图按钮测试一下自己的配置： 构建完成后，可以点击如图红框内的蓝色小按钮查看控制台输出： Jenkins+Jmeter环境搭建操作手册 一、环境&工具 Jmeter：本地的Jmeter 版本最好与Jenkins上的是一致的 查看Jenkins服务器上的Jmeter版本： 上传脚本工具：SVN 或者Git 。这2中工具作用均用来实现将你本地的脚本上传至Jenkins 服务器。（Jenkins服务器是不会运行你本地的脚本~~） 二、账号准备 Jenkins 账号：自己在Jenkins上注册就行啦 SVN / Git 账号：可在项目組内申请 三、环境搭建 3.1 测试脚本的上传 本文拿SVN举例。 S1、SVN在本地创建存储目录（不做详细介绍），将要自动运行的脚本文件夹放置该目录下 S3、提交：选中文件，右击，选择”Commit",显示绿色的勾后，及上传成功 3.2 Jenkins的项目构建环境配置S1 . 登录Jenkins S3. 创建任务（自动化任务） S5. 设置源码管理路径 S7. 构建环境：每次构建前删除上一次运行的workspace cd /usr/locallogs/jenkins/workspace/dhp_test/dhp_test1 JENKINS进入到路径中（存放sh脚本的路径） chmod 777 BookingcomRes.sh修改文件执行权限 bash BookingcomRes.sh运行文件 /usr/local/bin/sendmail.sh "test report" "yanan.fan@https://www.doczj.com/doc/e016070672.html," "EMAIL CONTENT" /usr/locallogs/jenkins/workspace/dhp_test/dhp_test1/report/Test*.csv 将运行结果写到CSV文件中并通过邮件的方式发送到我的邮箱 配置管理流程规定 (Ver1.0) 拟制：___________________ 审核：___________________ 签发：___________________ 目录 1.配置管理流程 (3) 1.1概述 (3) 1.2总体流程图 (3) 1.3软件需求分析阶段 (4) 1.4软件设计阶段 (4) 1.5制定配置管理计划 (4) 1.6配置库管理 (4) 1.6.1相关人员分配权限 (4) 1.6.2配置项 (5) 1.7版本控制 (6) 1.8变更控制 (6) 1.9配置审计 (8) 1.9.1配置审核的类别 (8) 1.9.2配置审核执行的时机 (8) 1.9.3不符合项的处理 (8) 2.0.0配置状态报告 (8) 2.0.1配置状态报告的目的 (8) 2.0.2配置状态报告记录的内容 (8) 2.0.3配置状态报告的生成 (9) 2.1.0发行管理 (9) 2.1.1交付管理 (9) 2.软件基线化规范 (10) 2.1正常开发期 (10) 2.2版本发布期 (11) 2.3项目发布期 (13) 3.Jira配置管理 (14) 1.配置管理流程 1.1概述 规范配置管理活动，确保配置项正确地唯一标识并易于存取，保证基准配置项的更改受控，明确基线状态，在贯穿整个软件生命周期中建立和维护项目产品的完整性和可追溯性。 1.2总体流程图 1.3软件需求分析阶段 参加需求分析会议，配置管理负责人记录，有关文档提交归档。如《需求分析》。 1.4软件设计阶段 参加设计阶段，为了详细制定配置管理计划。针对需求分析报告进行系统设计，配置时应说明系统设计的版本与需求分析报告版本的对应关系。设计书评审通过后，建立设计基线。 1.5制定配置管理计划 配置管理员制定配置管理计划，主要内容包括配置管理软硬件资源、配置项计划、备份计划等，审批该计划。 1.6配置库管理 配置管理员为项目创建配置库，并给每个项目成员分配权限。各项目成员根据自己的权限操作配置库。 1.6.1相关人员分配权限 项目经理： 1)与(有关负责人员)协商确定项目起始基线 2)接受配置管理计划，并按相关规定贯彻执行； 3)接受配置控制委员会的报告。 4)提出配置管理计划的修改要求； 5)提出管理管理的建议和要求。 配置管理员 1)编制配置管理计划； 2)执行配置项管理； 3)执行版本控制和变更控制方案； 4)编制配置状态报告； 5)配置库的建立和权限分配； 6)配置管理工具的日常管理与维护； 7)配置库的日常操作和维护 开发人员 份号：001 密级： XXXXXXXX项目 软件配置管理报告 XXXX-RPB-R01.00 XXXXXXXX公司 XXXX年XX月XX日 辑要页 文档修改记录 目次 1 范围 (1) 1.1标识 (1) 1.2系统概述 (1) 1.3文档概述 (1) 2 引用文挡 (1) 3 软件配置管理情况综述 (1) 4 软件配置管理基本信息 (1) 5 专业组划分及权限分配 (1) 6 配置项记录 (1) 7 变更记录 (2) 8 基线记录 (2) 9 入库记录 (2) 10 出库记录 (2) 11 审核记录 (2) 12 备份记录 (2) 13 测量 (2) 14 主释 (2) 1 范围 1.1 标识 本条应描述本文档所适用的系统和软件的完整标识，适用时，包括其标识号、名称、缩略名、版本号和发布号。 1.2 系统概述 本条应概述本文档所适用的系统和软件的用途。它还应描述系统与软件的一般特性;概述系统开发、运行和维护的历史;标识项目的需方、用户、开发方和保障机构等;标识当前和计划的运行现场;列出其他有关文档。 1.3 文档概述 本条应概括本文档的用途和内容，并描述与其使用有关的保密性考虑。 2 引用文挡 本章应列出引用文档的编号、标题、编写单位、修订版及日期，还应标识不能通过正常采购活动得到的文档的来源。 3 软件配置管理情况综述 本章应描述软件配置管理活动进展，与软件配置管理计划的偏差;软件配置管理活动与规程是否相符;对不符合项所采取的措施;完成软件配置管理工作的工作量等。 4 软件配置管理基本信息 本章应概述软件配置管理的基本信息，包括项目负责人、各级软件配置管理机构组成人员和负责人、软件配置管理所用的资源(如计算机、软件和工具)等。 5 专业组划分及权限分配 本章应列出项目专业组的划分、各专业组的成员以及各成员的权限分配，如专业组可分为项目负责人、开发组、测试组、质量保证组、配置管理组等，权限可分为读出、增加、替换、删除等。 6 配置项记录 本章所列出项目的所有配置项，包括配置项名称、配置项最后发布日期、配置项控制力度(控制力度可分为基线管理、非基线管理(受到管理和控制))、配置项版本变更历史、配置项变更累计次数等内容。 使用JIRA和Jenkins进行项目管理 (仅供参考) 1使用JIRA进行项目跟踪管理 1.1JIRA项目管理流程 1.1.1概述 项目的软件开发流程主要围绕实现一个个业务功能需求和非功能需求的需求分析、设计、开发、测试、发布验收，而参与人员最多的开发和测试环节是流程最容易出问题的环节，为有效使用JIRA进行项目管理，我们设计了以需求为主导的JIRA表单和流程（如下图）。 对应于软件过程的管理流程，本项目JIRA对应设置了以下的IssueType（问题类型）和3大管理流程： 【说明】 【需求单】：在需求分析、概要设计、详细设计阶段，将产生对一个需求的具体描述和实现设计描述交付到开发阶段，在JIRA中，体现为一份 需求单，这些交付件全部作为需求单的附件，需求单的来源包括： -需求阶段的原始需求，以一个业务功能为一份需求，通常在一周左右可以开发完成，例如“用户新增和查询功能”； -系统优化和变更：如果一些变更无法对应一份原始需求，需要创建一份新的需求单 ?【子任务单】在开发阶段，一份需求往往需要三四天甚至长得多的时间 才能完成，开发完成后也存在不断的优化和改进，因此，围绕需求在JIRA 上设置了以下的管理跟踪对象子任务单(SubIssueType) -开发任务单： -程序员拿到需求后，组长应该协调开发人员将需求分解为开发任务，在JIRA上创建任务单； -设计问题单： -程序员拿到需求中的设计进行评估时，如果发现设计文档或者需求有bug，应该记录在案以便协调设计小组完善，在JIRA上创建设计 问题单； -变更单 -但设计和需求人员需要对已经提交的需求和设计提交变更时，例如增加一个字段、变更原型样式、变更接口方法，均需要提交变更单； -评审BUG单 -主要是开发组长或者结对开发程序员在评审BUG时，将评审的BUG 记录为评审BUG； -测试BUG单 -主要针对前期开发阶段的冒烟测试，测试人员对已经实现的功能进行测试，保证流程能够跑得通，如果发现BUG则创建测试BUG单； ?【测试问题单】 -主要针对无法对应到一份需求产生的BUG ?流程设置说明 -根据参与者、小组分工，设置以下流程 -需求跟踪流程 -参与人员包括需求分析员、设计者、开发组长、程序员、测试组长、测试员、用户参与，只与需求单关联，但目前其他用户参与的流程 主要由开发组长完成。 -任务跟踪流程 -主要是开发组长和程序员两级人员参与，与开发任务单、设计问题单、变更单、评审BUG单，便于开发小组进行状态监控，部分单尽 管涉及到设计人员，但为降低流程协调工作量，均由开发人员在面 对面解决后对流程进行操作 -BUG跟踪流程 -主要是测试人员和开发组间的流程跟踪。 详细的流程图如下： 1.1.2需求跟踪流程 【流程重点说明】 -开发人员必须在接受到任务后点击“开始处理”，以便跟踪哪些任务正在处理中；任务完成后点击“完成”； -小组长在代码评审后，使用JIRA的批量流程操作功能，将完成开发的进行发布，在JIRA上点击“发布测试”； -测试部分分为两个环节：冒烟测试和集成测试； Jenkins使用总结 Jenkins安装 ●安装目录 （1）/usr/lib/jenkins/：jenkins安装目录，WAR包会放在这里。 （2）/etc/sysconfig/jenkins：jenkins配置文件，“端口”，“JENKINS_HOME”等都可以在这里配置。 （3）/var/lib/jenkins/：默认的JENKINS_HOME。 （4）/var/log/jenkins/jenkins.log：Jenkins日志文件。 ●任务构建频率： （1）在Schedule 中填写0 * * * *。 （2）第一个参数代表的是分钟minute，取值0~59； （3）第二个参数代表的是小时hour，取值0~23； （4）第三个参数代表的是天day，取值1~31； （5）第四个参数代表的是月month，取值1~12； （6）最后一个参数代表的是星期week，取值0~7，0 和7 都是表示星期天。 （7）所以0 * * * * 表示的就是每个小时的第0 分钟执行构建。 （8）每天两点构建H 02 * * * ●jenkins安装插件： （1）用户授权管理插件：Role-based Authorization Strategy （2）GIT插件 （3）Maven插件 （4）Sonar插件 （5）SSH插件 （6）Gitlab插件 ●Jenkins集成LDAP （1）Jenkins中ldap配置 （2）可以使用ldap中已经添加的已有账号进行验证测试，成功后如下图提示 （3）授权策略-不同用户不用项目权限配置 （4）进入系统管理下的Manage And Assign Roles （5）设置全局权限与项目权限 火灾自动报警系统是在保护对象发生火灾的情况下自动探测、显示发出火灾警报的装置。它广泛应用于现代化工厂、物资仓库、高层建筑、计算中心等建筑物内，对保证人民的生命和财产安全起着巨大作用。 火灾自动报警要经历安装、接线、调试、验收等诸多环节，其中调试是其中最重要的一个环节之一。说起调试，每个火灾自动报警系统都有其特有的调试软件，而每个厂家的调试软件只有其相关的调试人员才会接触到，相对于普通人来说也是比较神秘的，下面国产火灾报警品牌巨头一海湾的进行揭秘。 首先打开海湾调试软件工具，屏幕会出现输入密码界面 输入密码后进入GstCfg配置管理工具界面，界面有标题栏、工具栏、状态区域和编辑区域组成。 WRIVJ.A 右击状态区域内“控制器”可以添加控制器操作，GstCfg配置管理工具可添加的控制器有GST20C火灾报警控制器、GST500/5000 火灾报警控制器、GST900C火灾报警控制器、DH9000电气火灾控制器、以及KR9000可燃气体报警控制器。 控制器添加界面可以对控制器的名称，是否联网、以及新老国标等基本属性进行选择。 控制器添加完成后进入如下界面，在这了我们添加一个新国标地址号是01的GST500C型火灾报警控制器 欝E.H k^ITEHlJ-A A EW4U眠皿活冋1SB 畑：fi ------------------- ■ j ■* 可以在左侧框内的GST5000C控制器右击选择添加回路，选择回路数量进行添加。添加好的界面如下 图中右侧显示的就是设备定义的界面， 在这里可以完成对所有设 备定义数据的填写。最左边的一列是设备的二次码， 选中右击二次码 可以对其进行批量修改。 ML 士 HS-ti p -yi | mmv ■■ 離 ?皿心卸 Et? ■F ■?; *g ■ Mimi I q ? mum ? 卜 ii 1 卫 L J Ml?]i | iSH> M G . 口亠■史曲 ■ :石「 '| E P L \ b □ 1 B —帛?P L ?吐皿 Q fl 4 HKOt 阿沁0 □ ■ i 沁〈亍6 * 4 * V M IO? 1 t .：.?■：：:? >Q 4 | 1 i ?l?St 1 I I 0W"*E 0 L j 0 $ 川1 otltlt D L Qb”利1 ? 上理_； M |?|| fn- AhB D u 51- PS.m 1 h 一 ^ b 白 會 nsn 0?i-5HE 0 ￡ a>*3 Rfl J ~0 4 "t Al M IMF t 曲祐i b 1 Q V [| (^ICM OCMH 0 k 1 H 「 1 口*飓6 I 口 4 if 1 W 1 wi?ir CW4HL D ._"L g fi 曾 'P ' wwii 1 "T "?■ #￡ 厂 t 1 6 i i ' il DMAII D C n> A949I □ ；M bMtt i ? i> *!?■? 1 fi ；n t awt-^'S n U S *9 J 口 4 HUtil X 蘇Q k 汁”枕 0 I ；裁?1?2f ' t gMt 0 L as 1 4 i 31 i i g?p-M Q . k "■却捆 n ii ■ i 亦a 沁"厂 k H ■■盟耐 Q 4 |T ?J0? & MHK P 匚岭彗r.g 1 Q I * NIKI ￡M?E 0 =H 联1 I 4 i￡ —慣呻一 MMNE 6 I ? * . 1 C M M文件软件配置管理过程 XXXXXXXXXXXX (版权所有,翻版必究) 文档变更请求(DCR) 文档变更记录 目录 1 概述 (1) 1.1 目的 (1) 1.2 范围 (1) 1.3 术语与定义 (1) 1.4 参考文档 (1) 1.5 引用文档 (2) 2 过程目标 (2) 3 过程定义 (2) 3.1 责任人 (2) 3.2 输入 (3) 3.3 入口准则 (3) 3.4 过程活动 (3) 3.5 出口准则 (6) 3.6 输出 (6) 附录 A ：软件配置项/产品包标识 (8) A.1 文档的编号 (8) A.2 程序的名称 (9) A.3 软件产品包的标识 (9) A.4 系统、数据库、开发与支持软件工具的编号 (9) 附录 B ：配置项状态报告 (10) B.1 系统软件、数据库、开发与支持软件工具列表 (10) B.2 软件基线/配置项状态报告 (10) B.3 软件基线软件基线变更报告 (10) 附录 C ：软件配置管理测量报告 (11) 1概述 1.1目的 软件配置管理（简写为SCM）是维护项目软件整个生命周期产品完整性的重要活动，本文档明确规定了公司软件配置管理活动的目标和过程定义，为公司软件配置管理提供所遵循的过程、程序和指导方针。 1.2范围 本文档适用于管理公司所有软件项目在各阶段标识的软件配置。软件配置管理的大部分活动用“软件配置管理工具”实现。 1.3术语与定义 1.3.1软件工作产品：作为定义、维护或应用软件过程的一部分所生成的任何人工制品，包括过程描述、 计划、规程、计算机程序和相关文档，这些可能交付也可能不交付给顾客或最终用户。 1.3.2软件基线：软件配置项经软件验证、确认、评审和认定后，形成了软件基线，也就成了该阶段的一 个基准。下一个阶段只能在这个基准上进行开发活动。 1.3.3软件配置项：是指一个软件产品在软件生存周期各个阶段所产生或应用的各种形式（机器可读或人 工可读）和各种版本的文档、程序及其数据。 1.3.4SCCB：软件配置管理委员会（Software Configuration Control Board）（关于责任，参见“责任 人”）。 1.3.5SCM：软件配置管理(Software Configuration Management) 包括了标识软件工作产品、控制对 软件工作产品的更改、和维护在整个软件生存周期中的软件工作产品的完整性和可跟踪性。 1.4参考文档 1.4.1Mark C. Paulk，Bill Curtis，Mary Beth Chrissis，Charles V. Weber，Capability Maturity Model for Software （Version 1.1） 1.4.2Roger S. Pressman，Software Engineering –A Practitioner’s Approach (Fourth Edition) 1.4.3《计算机软件配置管理计划规范》GB/T 12505-90 1、创建测试场景 场景用于组织多个用例，执行时可以以1个用例为单位，即执行一个用例，也可以执行一个场景，即执行多个用例，执行的顺序按创建场景时添加的顺序。删除该场景时，会将该场景下的用例及数据一起删除。 创建场景步骤：在首页点击场景管理->新增场景->输入场景名及功能说明-> 提交即可 2、创建用例及数据 （1）增加用例 用例是用来组织测试数据，定位信息的（webUI），逻辑代码的。创建用例步骤： 首页->用例管理->选择所属场景->输入用例名及用例功能说明->选择用例 类型->选择消息发送状态->提交即可。对应的用例类型及消息发送类型的说明，如图： （2）用例列表页面 管理操作中，可增加业务逻辑代码，添加定位信息，数据等。 （3）用例执行体增加 在phoenix_develop工程下开发和调试用例，调试通过后，全部复制，粘贴到用例的执行体中。 如有以下用例代码： package org.phoenix.cases; import java.util.HashMap; import java.util.LinkedList; import java.util.Map.Entry; import org.phoenix.enums.LocatorType; import org.phoenix.model.CaseLogBean; import org.phoenix.model.InterfaceBatchDataBean; import org.phoenix.model.LocatorBean; import org.phoenix.model.UnitLogBean; import org.phoenix.proxy.ActionProxy; /** * 浏览器驱动测试类: * 通用方法API：https://www.doczj.com/doc/e016070672.html,monAPI().... * webUI/mobileUI用例API：phoenix.webAPI().... * 接口测试用例API：phoenix.interfaceAPI().... * androidappAPI：phoenix.androidAPI().... * IOSappAPI：phoenix.iosAPI().... * svnClientAPI：phoenix.svnClient().... * ftpClientAPI：phoenix.ftpClient().... * socketClientAPI:phoenix.telnetClient().... * ... * @author mengfeiyang */ publicclass TestBrowserDriver extends ActionProxy{ privatestatic String caseName = "浏览器驱动测试用例"; public TestBrowserDriver() {} @Override public LinkedList 软件配置管理流程 目录 1.配置管理流程 (3) 1.1 概述 (3) 1.2 总体流程图 (3) 1.3 软件需求分析阶段 (4) 1.4 软件设计阶段 (4) 1.5 制定配置管理计划 (4) 1.6 配置库管理 (4) 1.6.1 相关人员分配权限 (4) 1.6.2 配置项 (5) 1.7 版本控制 (6) 1.8 变更控制 (6) 1.9 配置审计 (7) 1.9.1 配置审核的类别 (7) 1.9.2 配置审核执行的时机 (7) 1.9.3 不符合项的处理 (7) 2.0.0 配置状态报告 (7) 2.0.1 配置状态报告的目的 (7) 2.0.2 配置状态报告记录的内容 (7) 2.0.3 配置状态报告的生成 (7) 2.1.0 发行管理 (8) 2.1.1 交付管理 (8) 2.1.1 软件配置管理员的处理规范 (8) 2.1.1.1 现阶段使用的版本配置服务器 (8) 2.1.1.2 主要操作流程 (8) 2.1.1.3 版本规范化处理 (8) 2.1.1.4 客户反馈问题处理 (8) 2.软件基线化规范 (9) 2.1 正常开发期 (9) 2.2 版本发布期 (9) 2.3 项目发布期 (9) 2.4 项目维护期 (9) 1.配置管理流程 概述 规范配置管理活动,明确配置项正确的唯一标识并易于存取,保证基准配置项的更改受控,明确基线状态,在贯穿整个软件生命周期中建立和维护项目产品的完整性和可追溯性。 总体流程图 软件需求分析阶段 参加需求分析会议,配置管理负责人记录,有关文档提交归档。如《需求分析》。 软件设计阶段 参加涉及阶段,为了详细制定配置管理计划。针对需求分析报告进行系统设计，配置时应说明系统设计的版本于需求分析报告版本的对应关系。设计书评审通过后，建立设计基线。 制定配置管理计划 配置管理员制定配置管理计划,主要内容包括配置管理软硬件资源、配置项计划、备份计划等,审批该计划。 配置库管理 配置管理员为项目创建配置库,并给每个项目成员分配权限。各项目成员根据自己的权限操作配置库。 相关人员分配权限 项目经理： 1）与（有关负责人员）协商确定项目起始基线； 2）接受配置管理计划，并按相关规定贯彻执行； 3）接受配置控制委员会的报告； 4）提出配置管理计划的修改要求； 5）提出管理的建议和要求。 配置管理员 1）编制配置管理计划； 2）执行配置项管理； 3）执行版本控制和变更控制方案； 4）编制配置状态报告； 5）配置库的建立和权限分配； 6）配置管理工具的日常管理与维护； 7）配置库的日常操作和维护； 开发人员 1）根据确定的配置管理计划和相关规定，提交配置项 软件配置管理计划示例 作者：赵文锋计划名CADCSC软件配置管理计划 项目名中国控制系统CAD工程化软件系统 项目委托单位 代表签名年月日 项目承办单位 代表签名年月日 1 引言 1．1 目的 本计划的目的在于对所开发的CADCSC软件规定各种必要的配置管理条款，以保证所交付的CADCSC软件能够满足项目委托书中规定的各种原则需求，能够满足本项目总体组制定的且经领导小组批准的软件系统需求规格说明书中规定的各项具体需求。 软件开发单位在开发本项目所属的各子系统（其中包括为本项目研制或选用的各种支持软件）时，都应该执行本计划中的有关规定，但可以根据各自的情况对本计划作适当的剪裁，以满足特定的配置管理需求。剪裁后的计划必须经总体组批准。 1．2 定义 本计划中用到的一些术语的定义按GB/T 11457 和GB/T 12504。 1．3 参考资料 ◆GB/T 11457 软件工程术语 ◆GB 8566 计算机软件开发规范 ◆GB 8567 计算机软件产品开发文件编制指南 ◆GB/T 12504 计算机软件质量保证计划规范 ◆GB/T 12505 计算机软件配置管理计划规范 ◆CADCSC 软件质量保证计划 2 管理 2．1 机构 在本软件系统整个开发期间，必须成立软件配置管理小组负责配置管理工作。软件配置管理小组属项目总体组领导，由总体组代表、软件工程小组代表、项目的专职配置管理人员、项目的专职质量保证人员以及各个子系统软件配置管理人员等方面的人员组成，由总体组代表任组长。各子系统的软件配置管理人员在业务上受软件配置管理小组领导，在行政上受子系统负责人领导。软件配置管理小组和软件配置管理人员必须检查和督促本计划的实施。各子系统的软件配置管理人员有权直接向软件配置管理小组报告子项目的软件配置管理情况。各子系统的软件配置管理人员应该根据对子项目的具体要求，制订必要的规程和规定，以确保完全遵守本计划规定的所有要求。 2．2 任务 在软件工程化生产的各个阶段中，与本阶段的阶段产品有关的全部信息在软件开发库存放，与前面各个阶段的阶段产品有关的信息则在软件受控库存放。在研制与开发阶段的阶段产品的过程中，开发者和开发小组长有权对本阶段的阶段产品作必要的修改；但是如果开发者或开发小组长认为有必要个性前面有关阶段的阶段产品时，就必须通过项目的配置管理小组办理正规的审批手续。因此，软件开发库属开发这个阶段产品的开发者管理，而软件受控库由项目的配置管理小组管理。软件经过组装与系统测试后，应该送入软件产品库，如欲对其修改，必须经软件配置管理小组研究同意，然后报项目总体组组长批准。关于软件配置要进行修改时的具体审批手续，将在第条中详细规定。 2．3 职责 在软件配置管理小组中，各类人员要互相配合、分工协作，共同担负起整个项目的软件配置管理工作。其中各类人员的分工如下： A．组长是总体组代表，他对有关软件配置管理的各项工作全面负责，特别要对更改建议的审批和评审负责； B．软件工程小组组长负责监督在软件配置管理工作中认真执行软件工程规范； C．项目的专职配置管理人员检查在作配置更改时的质量保证措施； D．各子系统的配置管理人员具体负责实施各自的配置管理工作，并参与各子系统的功能配置检查和物理配置检查； 一步步搭建jenkins持续集成平台 持续集成作为最先进的项目实践之一，逐渐在受到天朝软件公司的重视，笔者从事近1年半时间的相关工作，也无法游刃有余，用了很久jenkins了，也没有做个入门介绍给大家，惭愧，最近在迁移，顺便重新搞下，记录以飨读者. 【持续集成相关工具集】： CI-Server(Jenkins/Hudson.....) 代码管理工具（SVN/git...) java框架（maven) 覆盖率工具（c++:gcov java:maven cobertura插件） 静态扫描插件（jenkins插件） 覆盖率报表合并工具 jenkins二次开发api apache +php +codeiginter 配置 mysql +python 用来管理数据库 python-dev 下载链接 ........... 笔者将来会专门在持续集成板块介绍相关的工具集合 【安装Jenkins配置启动】： apache-tomcat-6.0.37-src.tar.gz + jenkins.1.556.war 自己搜索下吧 tomcat/bin下全部chmod +x ./* 把jenkins.war 拷贝到tomcat/webapps下 启动tomcat/bin 下startup.sh 查看8080端口是否启动 浏览吧：http://192.168.1.xxx:8080/jenkins 若想从局域网别的机器访问，则修改tomcatxxx/cong/server.xml Host name="xxx.xxx.xxx.xxx" Engin name="xxx.xxx.xxx.xxx" 同时设置防火墙(局域网其他机器打不开时可以试试) iptables -I INPUT -p tcp --dport 8080 -J ACCEPT iptables -I OUTPUT -p tcp --dport 8080 -J ACCEPT 【jenkins重启】 cd tomcat/bin/ catalina.sh stop kill pid(java) catalina.sh bin 【增加Slave节点】 1.salve初始化帐号（例：主10.129.145.112 新Slave:10.209.23.90） useradd jenkins -m -d /data/home/jenkins #创建jenkins帐号 2.拷贝jenkin主server上的slave.jar包/usr/local/tomcat/webapps/jenkins/WEB-INF/slave.jar 到新slave的/data/home/jenkins/slave.jar 3.配置： 1）.系统管理->节点管理->新建节点10.129.145.112:8081/jenkins/computer/new Jenkins部署及操作手册1Jenkins工作原理 2Jenkins安装 2.1软件包/插件 2.2部署 2.2.1J DK安装 下载JDK1.8版本进行安装，安装后进行系统环境变量配置： 2.2.2A NT安装 下载绿色版apache-ant-1.9.6拷贝至安装目录下(如： D:\tools\apache-ant-1.9.6)，配置系统环境变量： 2.2.3M aven安装 下载绿色版apache-maven-3.3.9拷贝至安装目录下(如： D:\tools\apache-maven-3.3.9)，配置系统环境变量： 2.2.4T omcat安装 下载绿色版Tomcat8拷贝至安装目录(如：D:\tools\tomcat8-jenkins)，配置D:\tools\tomcat8-jenkins\conf\server.xml文件，添加URIEncoding="UTF-8" 2.2.5J enkins安装 下载jenins.war包，拷贝至tomat的webapps目录下(如： D:\tools\tomcat8-jenkins\webapps\)，配置系统环境变量： (C:\Users\Administrator\.jenkins) ●启动tomcat，启动结束后，打开IE浏览器输入:http://127.0.0.1:8080/jenkins， 提示输入密码进行下一步插件的安装，安装插件有两种方式选择，一种是按它提供的建议方式安装插件，另外一种方式是用户指定选择安装插件。插件安装过程中需要等待较长时间。 ●插件安装：登录Jenkins，在系统管理页面打开插件管理，选择可选插件选项 卡，勾选需要安装的插件。 ●设置用户注册：登录Jenkins，在系统管理页面打开Configure Global Security， 访问控制安全域勾选允许用户注册。软件配置管理过程指导说明书(超级实用)
软件开发项目配置管理工具的选择
jenkins简单使用
Jenkins+Jmeter环境搭建操作手册
软件配置管理流程
16软件配置管理报告
使用JIRA和Jenkins进行项目管理
Jenkins使用总结_20180615
海湾配置管理工具的使用
SCMS软件配置管理过程
Phoenix自动化界面操作手册
软件配置管理流程
软件配置管理计划示例
一步步搭建jenkins持续集成平台
Jenkins安装部署及操作说明文档
相关主题
文本预览