SVN管理规范

<p>[TOC]</p> <h3>目前版本管理问题</h3> <ol> <li>生产环境、测试环境、SVN版本库版本不一致</li> <li>trunk目录较为混乱，递交无标准</li> <li>部分代码在trunk目录不是最新</li> <li>开发人员修改代码直接在线上修改</li> <li>客户定制项目统一递交到customs目录下</li> <li>数据库相关更新没有具体标准，导致在本地、测试环境搭建网站时，容易缺字段、缺表等问题</li> <li>开发人员递交代码是，TL无法检查功能完整性，只能检查代码是否符合规范</li> </ol> <p>以上存在的版本管理问题，很容易引发代码冲突，版本不一致，修复bug无法同步到其他版本，开发人员递交代码时容易递交错误代码，并且容易漏递交文件。开发人员将代码更新到生产环境时，只能通过ftp手动上传，上传时容易导致漏上传代码，上传断开时导致生产环境出现bug，并且针对该情况，ftp上传记录无法对递交人员追责，导致生产环境存在很大风险</p> <p><strong>（截止2022年3月15）</strong></p> <h3>版本管理规范方案描述</h3> <p>假设继续使用SVN版本管理规范，为方便维护，应严格区分稳定版本、开发版本、开发分支等，在trunk目录，除TL外，其他人禁止往trunk递交代码，代码统一递交到各自开发分支，由TL进行合并</p> <p>在SVN库中，分为三个目录，即：branches,tags,trunk。</p> <p>某个大版本需打tag到svn tags目录下，该版本为稳定版本，只允许合并bug修复分支，不允许在tags版本递交任何修改</p> <p>branches为分支版本,tags为稳定版本，trunk为开发版本。在开发阶段，开发人员在trunk开发版本上新增分支到branches中,命名规范可为：dev_名字_功能，开发人员开发完成后，将代码递交到自己目录，后由TL统一合并到trunk开发分支。开发人员分支要求切换到对应分支后，能在本地运行，禁止出现缺少文件等情。在功能开发完成或者bug修复后，需删除对应分支，需定时清理无用分支</p> <p>tags分支为稳定版本阶段，项目开发到某一阶段后比如svn版本号4011，需将该版本号新建分支到tags下并出示该tag的测试报告，在给客户部署网站时，以该版本为准。假设tag出现bug，需在该tag基础上，新增分支，bug修复完成后合并到该分支，如果该bug是版本公共问题，可将该bug同时合并到trunk主分支中。如果客户有定制需求，需在该tag中，新增一个客户定制分支，客户的所有定制，需在客户定制分支中开发，客户定制分支不允许合并到trunk或者tag中。如果客户定制分支中出现bug，并且是公共bug，则可新建bug修复分支，合并到trunk和tag中，如果仅仅是该客户出现问题则直接在客户定制分支中修复</p> <p>trunk主分支为开发分支，除TL外，开发人员禁止在该分支上直接进行开发。开发人员开发完成后，统一由TL进行代码合并，trunk版本代码为最新、最全的代码</p> <h3>代码更新到生产、测试环境规范</h3> <p>在开发人员开发完成并且由TL合并代码后，需更新到测试环境先进行测试，更新到生产环境不再由开发人员自行上传，而是交由运维人员在Linux中执行 <code>svn　update</code>命令，进行代码统一拉取。在服务器拉取执行版本代码后，需测试人员进行版本回测，保证测试环境代码没有bug。代码在测试环境测试通过后，再由运维人员更新到生产环境，更新到生产环境后同样需要测试人员进行版本回测。</p> <p>收回所有开发人员FTP权限。除特殊情况外一律禁止直接在测试环境、生产环境进行开发、调试。所有代码更新到线上环境时，均需要在本地测试无问题、无缺少文件后才允许在服务器中拉取代码。</p> <p>假设生产环境有bug需紧急修复，应在线上环境对应分支中，新增bug修复分支，在分支中修复bug后再由开发人员或TL合并到对应分支中，再交由运维人员在服务器中拉取代码，如运维人员不在，可由TL进行代码拉取。如有紧急问题需修改，可直接修改线上文件，修改后需将修复代码文件递交到SVN对应分支中。如果紧急bug不是那么轻易修复，需修改的文件较多，同样不允许在线上直接修改，应本地修改测试无问题后递交到svn，再由运维/TL进行拉取</p> <h3>SVN版本管理工作流</h3> <p><img src="https://www.showdoc.com.cn/server/api/attachment/visitFile?sign=110a9dd7e5340e13c3a29075aebe3fe3" alt="" /></p> <h3>分支规范</h3> <pre><code class="language-svn">|- project |- branches // 开发分支 |- custom // 客户定制分支 |- tags // 稳定版本分支 |- trunk // 主干</code></pre> <p>开发人员在进行项目开发、bug修复时，应基于trunk主干，在branches新建分支，分支应遵循以下规范：</p> <ol> <li>分支命名为小写</li> <li>开发分支命名格式为：feature_功能名_版本号_名字,例如:feature_wechat_1.0_cole</li> <li>bug修复分支命名格式为：hotfix_功能名_版本号,例如：hotfix_goods_1.1</li> <li>开发分支或bug修复分支完成并合并到主干后，需删除分支</li> <li>不允许在trunk上直接进行开发</li> <li>不允许在tags稳定版本上进行开发</li> <li>合并分支时，应检查代码是否冲突，是否会删除某些文件，解决冲突之后，才可以进行合并</li> </ol> <h3>代码递交规范 【目前可以实行】</h3> <p>在递交、合并、tag时，应详细注明修改了什么内容。合并了什么东西。是否有更新数据库结构、数据。应遵循以下规范</p> <ol> <li>在递交时，Message应标明更新了什么内容，修复了什么bug，增加了哪些功能，如果递交的是bug修复，并且bug较多，可填写bug在线反馈文档或obdoc反馈文件路径</li> <li>在递交时，如果分支在合并时有什么需要注意的，应在Message中标明</li> <li>如果分支中有数据库结构修改或者数据库数据修改(如ob_config)，应将数据库语句写在<code>application/install/data/update.sql</code>，sql应是可执行的sql语句，禁止存在语法错误的等问题，并且在Message中，应注明有数据库结构、数据变更，方便TL合并代码时，检查数据库语句</li> <li>在递交时，开发人员应检查自己代码是否符合开发规范，是否有大量空格、换行、多余注释，应尽量避免无效递交</li> <li>在递交时，依赖文件、打包后的文件、本地配置文件禁止递交到svn，应保证svn中代码的干净，整洁</li> <li>在合并时，应注意检查代码是否符合开发规范，数据库语句是否符合数据库规范，是否存在代码冲突，合并时是否会删除某些文件</li> <li>在打tag时，应注明该版本号、版本描述、版本注意事项，并且tags中的分支代码，拉取到本地，并且安装依赖后，是能够运行的，不应出现缺少文件、数据库表缺少字段等问题</li> <li>打tag后，应在线上搭建测试环境，由测试人员对该版本进行版本回测，确保该版本无明显问题，可以直接用来给客户搭建网站</li> </ol> <h3>当前版本管理规范切换到该方案需要做的工作</h3> <ol> <li>保证trunk稳定，能够直接从SVN拉取下来后，安装php和js依赖文件并且安装系统后直接运行 预计工时1-2个工作日</li> <li>trunk版本多余代码删除（插件代码、开发人员的配置文件、备份代码等） 预计工时1-2个工作日</li> <li>在整理1和2时，需暂停开发人员对trunk版本开发</li> <li>当前多余分支删除</li> <li>老项目后续客户定制问题，建议将dev1.3、dev1.2下的custom目录，基于对应dev版本新建分支，方便后续客户维护</li> <li>老项目目前在服务器上是没有使用svn版本的问题，老项目预计还是需要使用ftp手动上传，暂无法使用<code>svn update</code>更新</li> </ol>