关于Web应用开发流程的总结

标签：系统   单元   合并   分配   出现   pos   框架   源码   分布式   

假设最简单的情况，一个开发人员，开发所有的代码，一个测试人员。一个测试的服务器，一个生产的服务器。开发人员需要为公司开发一个项目，开发人员首先分析产品经理的需求，建立相应的模型，然后进行如下步骤：

1. 编写代码
2. 项目打包部署到测试服务器
3. 测试人员测试，将Bug提交给开发人员
4. 如果测试通过则进行第5步。如果仍然有Bug，开发人员解决Bug，并重复第2步，第3步。
5. 项目测试通过后，打包部署到生产环境

这样就完成了一次迭代。

但是随后，任务变多，开发人员增多，共同维护一套代码，采用Git进行版本管理，不同的开发人员将代码提交到同一个仓库。先建三个分支，默认分支master，和即将发布的分支release，和初始化分支initialize。master是主分支，是最新的代码。release分支就是即将要发布到生产环境的代码。开发人员在一个迭代周期的初期，拉取最新的master代码，并在此基础上进行开发。假如项目发布后出现了一个紧急的Bug，需要立刻修复，而这时新的迭代已经开始，此时项目负责人需要将release上的代码合并到initialize分支上，那么负责修改那个紧急Bug的开发人员就需要从initialize分支上拉取最新的代码，并在此基础上进行开发，Bug解决后，将initialize分支上的代码打包部署到测试服务器上，测试无误后，将initalize分支上的代码合并到release分支上，然后将release分支上的代码发布到生产环境。

资源网站大全 https://55wd.com 我的007办公资源网站 https://www.wode007.com

随后，庞大而臃肿的单体项目已经不能满足需求了，后面一次大的版本迭代开始对项目开始采用的分布式。一个整体的系统，进行分解，分解成最小程度依赖关系的单元，各个单元之间通过轻量级的数据交换和调用，这样做可以降低系统耦合度，且方便扩展，也可以合理分配资源。然而被拆解后，系统的容错率就会降低，假如单元A被单元B C所依赖，一旦A发生故障，可能会影响B C，不过现在也有很多框架可以解决这样的问题，提高容错率。

然后是打包方面的问题，目前都是将项目打成可以执行的文件包，或者是可以在容器中运行的文件包。然后部署在服务器并运行项目。这样手动操作未免较为繁琐，可以采用Jenkins持续集成工具。Jenkins本身也是一个服务，打个比方来说，开发到发布的各个环节就像一个个独立的机器，开发人员需要将每次生产出来的产品放到下一个机器中继续加工，这样很繁琐。而Jenkins就像连接各个设备的传送带，只需要在Jenkins一键操作，就可以完成一些工作。Jenkins配置流程大致如下：

1. 首先将Jenkins服务运行在一台服务器上，假设这台服务器叫做Assembly
2. 在Jenkins上配置好项目所在仓库的地址，这样Jenkins就可以调用版本管理工具拉取代码到Assembly
3. 有在Jenkins上配置好打包工具，这样Jenkins就可以调用打包工具将源码打包成可以执行的包（或是在容器内运行的包），假设这个包叫做Component
4. 假设有一台生产用的服务器叫做Produce，在Assembly和Produce之间建立通信，Jenkins调用传输工具将Assembly上的Component传输到Produce
5. 现在Component已经在Produce上了，Jenkins调用通信工具将一些命令告知Produce去启动Component的，这样Component就在Produce上运行起来了

之后，Jenkins的工作流程就是：拉取代码 打包项目 部署项目 运行项目。这样开发人员只需要将代码提交到仓库，测试环境和生产环境就能保持同步更新了。需要说明的上述只是一个抽象的总结，实际情况，很有可能Assembly和Produce是同一台服务器。 

来自：https://www.cnblogs.com/colin220/p/10176792.html

关于Web应用开发流程的总结

标签：系统   单元   合并   分配   出现   pos   框架   源码   分布式   

原文地址：https://www.cnblogs.com/ypppt/p/13371140.html