工作流

使用git带来的分支疑惑 git 为什么好，为什么要用 git ，这不是我本文想要说明的问题。 这里想要给大家分享一下自己使用过程中产生的疑惑，以及解决的这些疑惑的过程。话又说回来，我现在依然充满疑惑。真不知道30岁的时候会不会不惑。 在使用 git 过程中，它的分支功能让我真的欣喜若狂，不过这是把双刃剑，一不小心你会得到这种 git 路径图： 我的疑惑： 1. 那么团队中我们该使用怎样的分支策略来进行开发协作？ 2. 在多人的团队中，我们应该在 master 分支上直接开发吗？ 3. 如果线上产生了bug该通过什么样方式的分支去修复？ 4. 当有多个分支的时候，测试如何有效的参与进来每一个分支的测试？ 用成熟的工作流来解决问题 在解答上面的疑惑前，先介绍几个工作流，然后通过工作流的模式，来进行解答。因为我们必须在某种设定的情景下，才能讨论解决问题的思路。 下面三种工作流方式，都是采用功能驱动开发，也就是先有需求产生，然后诞生对应的分支，然后开发，最后合并回来，完成使命被删除。 Git flow Github flow Gitlab flow 关于这三种工作流的详细介绍，建议看看 这篇文章-阮一峰 我现在采用的是 Git flow ，经过自己的实践，确实好用，解决不少问题。然后如果发现与自己的实际情况有些出入，可以根据需求做出些变动调整。 我的选择 我选择了 Git flow

一、JBPM（java business process manager） 　　1、工作流管理流程 　　O--->定义工作流(使用流程设计器生成，png和xml文件，分别面向用户和系统) 　　 --->执行工作流（核心对象：流程引擎ProcessEngine） 　　 --->连接数据库（jbpm18张表，jbpm4_deploymen,jbpm4_deployprop,jbpm4_execution,jbpm4_hist_task,jbpm_hist_var,jbpm4_lob,jbpm4_task,jbpm_variable） 　　<---O 　　 　　 　　2、jbmp中的几个基本概念 　　 流程引擎 ，ProcessEnginee 　　*RepositoryService 　　*ExcutionService 　　*TaskService 　　 部署对象 （deployment）：一次部署一个或者多个文件到数据库中（png，xml，zip） 　　 流程定义 （processDefinition）:获得并解析xml，解析xml文件中的内容，内容即流程定义的规则，工作流jbpm就是按照流程定义的规则往下执行的。与流程定义相关的表， 　　　　jbpm部署流程定义的表：select * from jbpm4_deployment; 　　　　jbpm流程定义的表：select *

Activiti简介 Activiti是一个开源的工作流引擎，它实现了BPMN 2.0规范，可以发布设计好的流程定义，并通过api进行流程调度。 Activiti 作为一个遵从 Apache 许可的工作流和业务流程管理开源平台，其核心是基于 Java 的超快速、超稳定的 BPMN2.0 流程引擎，强调流程服务的可嵌入性和可扩展性，同时更加强调面向业务人员。 Activiti 流程引擎重点关注在系统开发的易用性和轻量性上。每一项 BPM 业务功能 Activiti 流程引擎都以服务的形式提供给开发人员。通过使用这些服务，开发人员能够构建出功能丰富、轻便且高效的 BPM 应用程序。 1.安装Activiti插件，我用的是eclipse 2、弹出如上窗口，然后填写插件名称和安装地址 Name: Activiti BPMN 2.0 designer Location: http://activiti.org/designer/update/ 按提示安装即可，安装完了重启eclipse 3.新建的时候出现这两个就对了 4.新建maven工程并配置pom.xml <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi

“工作流”在互连网上越来越流行了， 可是工作流到底是什么呢？它是一项技术、一个标准还是一种解决方案？ 到底什么是“工作流”啦？ 在计算机网络的环境下，这种流表现为信息和数据在多个人之间的传送。根据国际工作流管理联盟 (Workflow Management Coalition ， WFMC) 的定义，工作流就是“一类能够完全或者部分自动执行的经营过程，它根据一系列过程规则、文档、信息或任务能够在不同的执行者之间进行传递与执行”； IBM Almaden 研究中心给出的工作流定义是：“工作流是经营过程的一种计算机化的表示模型，定义了完成整个过程需要的各种参数。这些参数包括对过程中每一个步骤的定义、步骤间的执行顺序、条件以及数据流的建立、每一步骤由谁负责以及每一个活动所需要的应用程序”。 从工作流定义中可以看出，工作流是经营过程的一个计算机实现，而工作流管理系统则是这一实现的软件环境。而工作流技术为工作流自动化和构建流程应用提供基础平台，实现了流程逻辑与业务逻辑的分离，支持业务流程的分析和规范化定义以及业务单元的自动组装，降低了复杂流程应用的开发难度， 提高应用系统的管理效率。 工作流技术重点研究内容包括：工作流引擎、工作流管理集成机制、建模工具、协同工作机制、流程设计器和流程监控工具等。而在工作流在流程管理中的应用分为三个阶段：流程建模、流程仿真和流程改进或优化

原文链接： Github Actions 学习指南 基于持续继承和持续开发的软件开发的最佳实践，GitHub 推出 Actions 功能。监听围绕代码仓库管理的各种事件，比如 push 和 pull_request 事件，触发提前计划好的一系列步骤，即工作流。这些步骤用 YAML 文档记录。触发工作流包括了构建和测试。这些工作流可以在 GitHub 的服务器上执行，开发者也可以在自己的服务器响应从GitHub触发的事件来执行工作流。 持续集成与持续开发 CI，全称是 Continuous Intergratiion，意思是持续集成。CD，全称是 Continuous Development，意思是持续开发。它们是一种软件开发与构建部署的最佳实践，或者称作一种行为指导或思考方式。它鼓励团队成员频繁地向代码仓库提交代码，这通常意味着能更快的检测出软件和代码中存在的错误，减少开发人员在查找产生错误的源头时需要检索的代码量。 这就像吃自助餐，为了减少粮食的浪费，餐厅建议顾客“多次少取”。就好比我们每餐吃的事物，听谁说建议“多餐少吃”，每一餐适可而止。每次向代码仓库提交少量代码，且这些代码只做一件事，明确每次提交的意图，并鼓励多次提交。但这种进餐方式并不适合所有人，比如没有一天除了三餐没有其他时间进餐的工作者。就像 CI/CD 并不适合所有软件项目。 每一次将代码提交到代码仓库，就可以使用

现状 团队之前使用SVN进行代码管理，也没有很好的利用分支管理代码版本。版本冲突问题比较严重，版本库里的代码不能作为稳定代码。 开发人员永远不知道生产上代码长啥样（环境上是编译后的jar），提测需要跟测试版本比较，上生产需要跟生产版本比较，混乱的一匹。 基于以上原因(尽管svn也有办法解决版本问题)，直接在团队里推行了git版本管理，部署了gitlab做管理工具，并参考了网上各种资料以及以前公司的处理经验，制定了一套代码管理方案。 解决方案 基于gitlab进行的代码权限、流程管理 代码分支 master分支 生产代码版本 qa分支 测试代码版本 dev-xxx 开发代码版本(xxx表示版本号) gitlab角色 gitlab角色 team身份 fork团队代码 提交到个人仓库 申请合并到团队仓库开发分支 合并到团队开发分支 申请合并到团队qa分支 合并到团队qa分支 申请合并到master分支 合并到团队master分支 备注 Reporter 开发人员 √ √ √ Developer 项目leader √ √ √ √ √ Master 测试人员 √用不到 √用不到 √用不到 √用不到 √用不到 √ √ √ 代码开发管理流程图 来源： https://www.cnblogs.com/coderzl/p/7491143.html

我们来模拟一下工作中的问题： 假如说，产品经理提出一个需求，我们进行开发 1、首先，我们通过sourcetree来创建一个demo3的一个仓库，并创建一个gui_demo.txt的一个文件 随后便完成添加、提交 假如说产品经理突然需求变更 所以我们就在工作区，打开资源管理器，找出刚才的gui_demo.txt，添加需求变更 我们也发现，当修改后的gui_demo.txt文件在工作区变成了橙色，随机我们添加到暂存区 当我们准备要提交到仓库时，产品经理突然又说之前变更的不需要了，心里一万句mmp，我们可以通过右击gui_demo.txt，选择丢弃，就可以了，也就是暂存区到工作区的回滚 变更也就不见了 到了第二天，产品经理提出了一个需求，我们完成后添加并且提交 我们已经提交了第二次的需求，产品经理突然说不需要了 这时需要重置到第一次的分支，右击first commit，并选择 2、接下来我们通过命令行git bash来操作一下以上的步骤 我们手动在本地资源demo4文件夹初始化为仓库，并在demo4下创建一个git_bash.txt 随后查看git仓库的状态 显式红色说明这个文件还在工作区，还没有提交 接下类通过git add 命令来添加到暂存区，再通过git commit 把文件提交到本地仓库 提交后准备下班，产品经理临时又提出了一个需求 查看仓库状态 我们提交到暂存区，

ActivityExecutionContext 简称 AEC ：用于描述 Activity 的执行环境。当宿主应用程序调用工作流的 Start() 方法时创建活动的执行环境。可以通过 AEC 执行或取消 child activity 。通过 AECparent activity 能控制 child activity 的执行状态，其它的 activity 的状态由工作流引擎控制。只有在创建完成 AEC 后才能将 Activity 设置成 Closed 状态，否则将由工作流引擎抛出异常。 静态属性名称 静态属性 描述 CurrentExceptionProperty 描述在工作流实例执行期间遇到的异常。该属性只有在 activity 返回 faulting 状态时才有值。 属性名称 属性 描述 Activity 获取当前正在执行的 Activity ContextGuid 获取与 Activity 关联的 ContextID ExecutionContextManager 获取与该实例关联的 ActivityExecutionContextManager 。 该属性可以获取新的 AEC 。目的是由于 WhileActivity, ReplicatorActivity 或 ConditionedActivityGroup 活动多次重复执行 child activity ，但每个

软件工程与UML笔记 第一章 面向对象软件工程概论 要求学习的内容： 软件危机 软件工程的由来 软件工程的定义 软件工程的范畴 软件工程实践的目标 软件开发包含的活动 软件维护的成本 修复bug的代价 一.软件危机 软件定义： 软件是程序以及开发、使用和维护程序所需要的所有文档。 软件危机定义： 软件开发和维护过程中遇到的一系列严重问题 表现： 对软件开发成本和进度的估计不准确； 软件产品质量很不可靠； 可维护性差，软件的文档资料不完整和不合格； 软件成本逐年上升； 软件开发生产率不高，不能满足客观需要。 软件危机原因： （1）人们对于软件概念与范畴的理解。 早期软件工程师崇尚个人英雄主义，整个软件开发通常处于一种无序的状态。他们大多认为编写程序就是软件开发的全部。这种观念会导致随着软件规模的增大，程序员对于文档的忽略与不重视，使得软件开发产品的不健全与维护困难。 （2）软件的规模日益增长、设计日益复杂。 Visual Studio/Office等（M->G） （3）软件开发组织发生变化。 在上述因素发生变化的同时，软件开发组织也在发生着变化。早期开发一款小型软件，可能1-2个开发人员就可以完成。然而随着软件规模的飞速增长，软件开发组织也在同比例增长，由单打独斗的状态改变为一个团队若干开发人员共同研发一款产品。人员由一个变成团队协同开发，这种组织形式的转变

版本控制 几乎是所有开发项目的必备， Git 是目前主流的版本控制系统，下面介绍几种常用的工作流程。 目录： 最简模式 特征分支 开发分支 开发 + 特性分支 发布分支 1. 最简模式 这是最简单的工作流模式，只使用 master 分支。 这种方式只适合于非常小的项目，例如个人项目。 当团队增长后，这种方式会极其混乱，产生大量的代码冲突。 2. Feature 特征分支 在上种方式上添加了 feature 特征分支。 每个 feature 分支都是用来开发某个新功能，以便与项目的其他部分隔离。 当 feature 分支中的功能开发完成后，这个分支就合并到 master 分支。 所以 feature 分支的生命周期比较短。 3. Developer 开发分支 开发分支基于 master 分支创建，并与 master 一样长期存在。 开发分支是开发时随时提交的代码，master 分支中是达到可发布状态的代码。 这种模式与最简模式一样，只适合非常小的团队。 4. Developer + Feature 混搭 这2种策略可以很好的混合使用。 master 分支中总是可发布的代码。 feature 分支只与 developer 分支合并。 当 developer 分支中的代码测试通过后，合并到 master 分支，然后发布。 5. Release 发布分支 在上一种模式上进行了扩展