不久前，在我们公司的一个项目中，决定最终放弃使用Subversion来存储和版本化代码，而改用Git。
过渡的主要目标如下：
- 提高开发过程的透明度。
- 在将更新更新到测试环境之前，实施强制性代码审查程序。
- 实施持续集成以在代码检查后构建更新并将其安装在测试环境中。
实现这些目标的先决条件是使用GitLab（该Git服务器已由客户使用，并且那里已经有属于解决方案前端的代码）和Jira（也已由客户使用）。
有人建议使用Git Flow作为目标开发模型，并向其添加评论代码。 这种事实上的开发模型已经成为开源软件开发的标准，并且被大多数行业巨头使用。 这就是为什么它的支持已内置在许多使用Git的流行工具中的原因。 关于其使用的主题，已经写了大量的材料；在最初的熟悉中，我会引用其中最成功的材料： 一和二 。
就其本身而言，该模型仅提供代码维护的一般原则，而忽略了其编写过程。 因此，包括审查代码在内的所有其他内容的实现都取决于特定的Git服务器。 在这方面，GitHub最方便：它最初是作为大量独立开发人员协作的平台而构建的，它允许您限制存储库中发送提交（Push）的权限，并具有创建发送代码请求的能力。 此外，GitLab提供了自己的工作流来维护名为GitLab Flow的代码，该代码量身定制以使用GitLab CI。 因此，在GitLab中，未实现用于创建发送代码请求的功能，建议使用分支合并请求来查看更改代码。 为了在项目上构建和安装工件，已经使用了Jenkins，它允许您灵活地创建和配置组装和部署任务，并且决定不切换到GitLab CI，同时拒绝使用GitLab Flow的想法。
我还注意到，该项目已在Jira和Git中配置为集成。 在Jira的Git插件中，添加了一个用于存储源代码的存储库以进行跟踪，在GitLab中，将该存储库配置为与Jira集成，在存储库的“集成”部分中。
为了解决此问题，开发了一种用于处理代码的工作流，该工作流的结构与Git Flow相似，但每次使用GitLab对主要流程分支（develop，release-n和master）进行更改时，都可以进行代码审查。 接下来，将描述所产生的过程，以及持续集成和将软件交付给与之相邻的字符串的阶段。 括号中是要执行的相应命令。
为存储源代码而创建的存储库被上载到本地存储库（git clone），并在其中初始化了Git Flow（git flow init）-除了master分支（用于创建标签以存储稳定版本）之外，还创建了开发分支（主开发分支，位于（集成了功能分支，发布和修订），设置了功能分支的掩码，发布和修订，并且还过渡到了develop分支。
接下来，将当前来自Subversion的源代码分支转移到工作副本，将代码提交（git add -A + git commit -m“提交消息”）到本地存储库的develop分支，并将其上载到远程存储库（git push origin development）。 之后，您可以开始使用Git对代码进行版本控制来开发新功能。
在开发过程中，根据正在执行开发的Jira任务代码，下载了当前版本的developer分支，并从中创建了分支，用于开发新功能（git flow功能启动MYFEATURE）。
自动执行到创建的分支的过渡（git checkout MYFEATURE），开发计划的功能并将更改提交到本地MYFEATURE分支（git commit -m“ Commit message”）。 请注意，为了正确集成Git和Jira，应在提交消息中指出此修复适用的Jira中的提交代码。 然后，这些提交将显示在与它们相对应的任务中以及项目的“ Git提交”部分中，借助它们您可以明确确定特定发行版中包含的内容。
开发选定任务的功能并准备好将其提交给测试环境后，创建的提交将上传到具有相同名称的远程分支（git push -u origin MYFEATURE），并向团队负责人或其代理人提出将下载的分支与开发分支合并的请求。
要请求合并，开发人员解决合并冲突（如果有），并且开发团队负责人（或代理）进行代码审查，在此期间，可以创建其他提交（git commit -m“提交消息”），并对收到的评论进行更正。在代码检查期间，将其添加到具有新功能的分支中并将其发送到中央存储库（git push -u origin MYFEATURE）。 成功完成审核后，团队负责人（或代理人）确认分支机构的合并。 在这里，合并后设置删除分支的标志并不是多余的，否则分支的数量会迅速增长到不雅规模。
为了确保在GitLab存储库中的持续集成，在“集成”部分中配置了一个Web Hook，该Web Hook调用Jenkins任务以在测试环境上构建和安装新功能。 Jenkins使用用于Git的插件下载源代码，从中获取任务的名称，并使用Jira API请求已更改并需要组装的组件列表，启动构建过程，运行单元测试，并在成功通过后加载所创建的工件。在Sonatype Nexus上安装，并将它们安装在测试环境中。 如果在其中一个阶段发生故障或单元测试失败，则在Telegram插件的帮助下，开发团队会收到有关构建结果的通知。 如果安装成功，则会通知质量检查团队该任务已准备好进行测试。
如果出现缺陷，则下载当前版本的develop分支，并从MYFEATURE分支与develop分支的合并提交中创建hotfix-MYFEATURE分支（git checkout [BASECOMMIT] -b hotfix-MYFEATURE）。
创建时，将自动对创建的分支进行检出，更正并将更改提交到本地分支hotfix-MYFEATURE（git commit hotfix-MYFEATURE -m“提交消息”）。 更正完成并准备提交到测试环境后，它们将被推送到具有相同名称的远程分支（git push -u origin hotfix-MYFEATURE），并与develop分支一起创建合并请求。
为了请求合并，开发人员解决合并冲突（如果有）并执行代码检查，在此期间可以创建其他提交，并更正收到的注释。 审核成功完成后，分支合并。 将补丁转移到developer分支后，Web Hook会立即调用Jenkins中的任务来构建，运行单元测试，将创建的工件加载到Sonatype Nexus并将补丁安装在测试环境中。 类似的通知机制适用于更正。
如果所有缺陷都已修复，那么将下载开发分支的当前版本，并从hotfix-MYFEATURE分支到开发分支的合并提交中，创建release-mn分支（git flow发布启动RELEASENAME [BASECOMMIT]）。
创建发布分支还会初始化Web Hook的启动，以调用Jenkins中的任务，该任务将从Git下载源代码，从发布分支中获取发布分支的名称，然后使用Jira API查询发布任务中已更改的组件列表，并从Sonatype Nexus下载当前版本并将它们设置为回归测试环境。 在回归测试环境上安装该版本后，将运行脚本以准备进行测试的环境（应用程序重新启动，清理数据库等），并运行回归自检以检查主要系统功能的运行情况，从而使用Jenkins的Allure Reports插件生成报告。 安装后，质量保证团队会在Telegram中收到有关自动测试结果和准备进行手动回归测试的发布的通知。
如果在回归测试期间出现缺陷，那么将下载release-mn分支的当前版本，并从最后一次提交开始，通过Jira中的缺陷名称创建hotfix / BUGNAME分支（git checkout -b hotfix / BUGNAME [BASECOMMIT]）。
将自动对创建的分支进行检出，进行必要的更正并将更改提交到本地分支修补程序/ BUGNAME（git commit修补程序/ BUGNAME -m“提交消息”）。 校正完成并准备提交给回归测试环境后，它们将被推送到具有相同名称的远程分支（git push -u origin hotfix / BUGNAME），并使用release-mn分支创建合并请求
为了请求合并，开发人员解决合并冲突（如果有）并执行代码审查，在此期间可以创建其他提交，并更正代码审查期间收到的注释。 这些提交也将提交到本地分支修补程序/ BUGNAME（git commit修补程序/ BUGNAME -m“提交消息”），并将它们推送到具有相同名称的远程分支（git push -u原始修补程序/ BUGNAME）。 审核成功完成后，分支合并。 合并将初始化Web Hook的启动，以调用Jenkins中的任务，与上一个相似，但不同之处在于，它从Git下载代码，从中获取缺陷的名称，使用Jira API请求作为修订的一部分的组件列表，收集这些组件，下载到Sonatype Nexus并将其安装在回归测试环境中。 此外，通过类推，为自动测试准备了环境，运行了回归自动测试，并通知了其结果。
修复所有缺陷后，将发行版安装在生产环境中。 为此，将release-mn分支与develop和master分支合并，并创建一个release标签。
创建后，它启动Web Hook的启动以调用Jenkins中的任务，该任务从Git下载源代码，从中获取发行号，然后使用Jira API查询发行版中包含的任务列表以及作为这些任务一部分而更改的组件，之后该工具会从Sonatype Nexus中抽出最新版本的工件，并将其安装在生产环境中。
对于销售修补程序，决定使用与发行版相似的过程-否则所做更改的测试阶段将丢失。
在实施该流程时，还对没有使用Git和GitLab工作经验的员工进行了培训，为此制定了适当的培训计划。 有了它，您自己就可以进行使用Source Tree和Intellij IDEA与Git以及GitLab进行代码审查的培训。 在下一篇文章中，我将给她补充插图。