代码库管理流程和开发中的一些问题

一 代码仓库管理

有效做好代码库的管理,对于复用和维护有着极佳的作用.我们公司现在使用git版本管理器来对代码进行管理,现在描述此问题.
补充:流程的描述是没有问题的，但是，有其适用的范围，这套流程，适用于大公司，客户成熟，开发流程完善，方可奏效，小公司的话，另外做其他的讨论了。但是还是这么些技术。当然，做微信开发的时候，应该采用其他的方案，毕竟微信开发中不能轻易的换服务器。

代码仓库结构

首先如下图:

仓库实例

结构的说明

服务器B:是生产环境的服务器

1. 里面将不用任何git之类的版本管理工具,不提交任何的测试代码,所有放在这儿的代码都是测试通过的代码,git会导致代码仓库臃肿等,存在管理不善隐患等问题.
2. 测试通过的代码,打成压缩包放在项目目录,直接解压到项目目录使用,每次有版本的更新,用新的版本命名压缩包,在解压到项目目录,之前的版本代码被覆盖,之前版本的解压包,作为备份,任然存放在项目目录,供追溯.
3. 此个服务器的代码压缩包,是来源于服务器A中测试完备的,为了平滑部署,服务器A和服务器B的数据库配置,数据库名,运行环境必须是一模一样的.

服务器A:是开发时候测试环境的服务器

1. 里面为了方便测试,这台服务器可以借助各种版本工具服务开发测试,比如git,其代码应该来自于git仓库(本地或者远程).
2. 这台服务器,也可以作为一个备用的服务器,当线上项目出问题时候,可以马上使用这个服务器.
3. 项目的测试必须在这个服务器上完全通过,然后再打包发送到服务器B.

本地代码仓库:是开发人员开始时候的本地环境

1. 初始代码应该来源于远程代码托管库,方便版本的控制.
2. 有git等多种便于开发的环境

远程代码仓库:便于协同,统一建立的仓库

1. 最开始代码仓库从此建立,开发者从这儿clone到本地,进行开发,可保持所有人可跟踪,代码统一.
2. 开发者可以推自己的代码变动到此.
3. 服务器A(测试环境)的代码,由此处clone或者pull下去,少数时候允许push

开发中的流程

• 建立项目时候,由管理者在git.oschina.net等远程仓库上先初始化项目,各个开发者再从仓库中clone到各自的主机进行开发,变动推送到远程托管代码库
• 开发者开发过程中,需要线上测试的,可以从远程仓库拉倒服务器A进行测试
• 当要正式上线的时候,必须在服务器A完成所有测试后,没有问题了,打包服务器A上的代码,发送的服务器B(生产环境),其中,两个服务器的项目环境必须一模一样;发送到B的代码解压后,即可用,压缩包作为一个版本,保留在生产服务器的项目目录下作为备份
• 当要更新项目,或者维护,或者有大的改动时候,在本地完成后,必须推送到测试服务器A,进行测试,完全没有问题后,在打包到生产环境服务器B,解压到项目,替换上个版本,压缩版作为一个版本,存留在项目目录

描述大致如下图:

仓库代码流转图

注：在上述的情况，从服务器A到服务器B的过程中，“打包到生产环境”这个步骤，不一定是这样的，如果变动比较小的话，这么搞反而很复杂了，如果每个版本变动很大，上述的更新是实用的。如果变动不大的，我觉得，还是使用git或者svn等来进行管理（还有一些自动化集成的工具不是很了解，等到以后了解以后再说喽）。

---

二 关于项目构架----前后端分离

前后端分离是一种经过实践的,无论在协作,维护还是性能方面,都是非常出色的方法.

介绍

含义:很明显,前后台分离,就是从构架,到开发,到部署,整个流程都遵循前台,后台代码独立,不融合的方法.

优势:

• 开发过程中,前端开发者,只用顾忌html,css,js和数据的传送和接受(ajax),模板的渲染(juicer,vue).后台开发者,只用顾忌数据库的建立,数据结构的分析,后台代码逻辑的构建,接受前台数据和数据的返回即可,无需接触到前台的代码,开发者权责分明,专业度强.
• 部署代码时,前台采用nginx部署,后台采用apache;nginx在单单的静态资源如css,js,image的处理上,有着apache无法相比的性能,扛并发性十分强,还可以做负载均衡,对于很多项目都是后台的请求没有前台的多,所以nginx很实用;后台的代码交给apache处理,非常的稳定.无疑可以大大提高性能和抗兵法的能力.

流程示意图

前后端分离