documents/workflow.md

维护linx6.0.42.41操作系统的工作流程

1、背景

当你拿到此文档仔细“研读、学习”的时候，我猜有八成的可能，你没有在维护linx6.0.42.41的环境中工作过，要不然你肯定不会浪费你宝贵的时间来读我这个绿得发亮的作者写的文档。维护linx6.0.42.41的工作流程本身并不能说是有多么复杂吧，但是它也涉及到一些流程步骤，要是不清楚这些步骤，还真是没法工作。就像你新接触一款工具软件的时候，经常是一些简单的操作步骤弄得人分不清东西南北。问别人？是，这个方法最直接，也省事，可是老问别人肯定不行，打扰了人家，人家给你甩个脸色，一天下来整个人都感觉不好了。出于这些方面的考虑，在这里我会详细介绍维护linx6.0.42.41操作系统的工作流程。写这篇文档的时候，我也刚开始维护linx6.0.42.41的工作，我会尽我最大的努力把在维护工作中需要做的一些工作，具体的步骤交待清楚，让这篇文档能够切实帮助到你。 因为在我写这篇文档的时候，咱们团队的前人已经在一些技术细节上写出了参考文档（比如怎么提交bug，维护linx6.0.42.41时常用的git命令等），这时我会指出你可以在哪里找到这些文档进行阅读，如果对于某一个问题，在我写这篇文档的时候还没有参考资料，那我会把这个问题的解决方法写出来。 所以，这篇文档的写作目标是让你对维护linx6.0.42.41操作系统的工作流程有个整体的把握，做到胸有成竹；指出相关资料的存放位置，方便查找；对一些“没地方去找”的问题作出详细的补充说明。

2、进入正题

在linx6.0.42.41的维护工作中，当有一项任务交给你的时候，你就进入了这个工作流程，这时候你需要完成的步骤是：在bugzilla上提交bug、在gitlab中创建分支、在你创建的分支上解决问题、去bugzilla上提交评审、查看邮件确认你提交的评审是否通过、如果没通过肯定是接着改，如果通过就去gitlab创建mergerequest、组长会将你创建的分支合并到主分支上、系统会自动出盘，你会以邮件形式收到新盘的下载地址。新盘出来后会交给测试人员进行测试，如果测试通过，那你的工作就算是完成了，工作流程到此结束，如果测试没有通过，那么继续你的工作吧，直到什么时候通过为止。下面我会逐条说明工作流程中的每一个环节:

1. 提交bug

当你的组长告诉你出了什么问题（比如编个包、或者写个文档之类的）的时候，你首先得去bugzilla上提交一个bug，这里有一个指导文档点击查看，会告诉你怎样提交一个bug。当你提交了一个bug之后，bugzilla会以邮件的形式告知维护团队中的每一个成员，这些人都会知道出了什么问题，以及谁会去处理这个问题（因为这个问题是以邮件地址指派给某一个人的，写这篇文档时，咱们其实是从自己给自己指派问题的方式展开工作流程的），这时的bugzilla就像是一个论坛，大家可以针对你所提出的这个问题展开讨论。 你提交了一个bug，肯定是针对特定的问题，提交完这个bug后相当于对这个问题正式“立项”了，bugzilla会为这个问题生成一个唯一的bug号来跟踪它，通过bug号可以方便地定位到某个问题。

2. 在gitlab中创建分支

熟练掌握gitlab的基本操作是咱们在维护linx6.0.42.41的环境中工作的基本要求，这篇指导文档点击查看 列出了在维护linx6.0.42.41的工作环境中经常用到的命令，以方便查阅。现在咱们要创建一个分支，创建分支简单（具体方法在下一条中列出），但是，以什么名字命名这个分支呢？随心所欲起一个自己认识的名字？肯定不行，因为咱们是在维护linx6.0.42.41的环境中以团队新式工作的，不能随便命名？那该怎么命名，问问谁？其实，谁也不必问，这时候提交bug的时候生成的那个bug号就有用了。工作环境要求，以提交bug的时候生成的bug号为新分支的名字，创建新的分支时，一定要在4.2/daily-build这个分支上进行。

3. 在你新创建的分支上解决问题

创建完新的分支后切换到这个新的分支上，解决bugzilla中提出的问题。其实，创建分支，切换到新的分支，这两个动作通过一条命令来完成。比如新生成的bug号是xxxx，那么可以用命令git checkout -b 4.2/xxxx，来完成创建新的分支，并且切换到新的分支上的动作。之所以在两条介绍中完成一条命令，是为了让我的文档看上去条理更清楚。 现在已经切换到你新建的分支上了，那你就可以在你本地的仓库中去完成你的工作（编译软件包，编写文档等）了。完成了你的工作之后进行提交，完了推送到远程仓库中就行了。 在这一个步骤中还有一点需要注意，那就是在git中提交改动（git commit）的时候，那个提交说明的格式是有要求的，具体按照怎要的格式书写提交说明，这里有一篇指导文档点击查看，按照这个要求来书写提交说明。提交的时候使用命令（git commit -s)就到了这篇文档开始时描述的界面。

4. 去bugzilla上提交评审

当你将自己的工作成果推送到远程仓库的时候，谁也不能及时知悉你完成了这项工作（当然你自己是知道的，但有什么用呢？目的是要让别人知道），这时你得去bugzilla上提交评审（我认为，本质上就是请求别人查阅的意思，随便你怎么理解，记住就好）。 具体的操作步骤为：通过bug号或其他途径在bugzilla上找到你之前提交的bug的那一页，页面上有个Add an attachment（没错，就是用来添加附件的，这里的”评审”功能被这个软件的设计者归类到了附件里头而已，点进去你就知道了），找不到？用ctrl+f搜一下。点击进入，进去之后，在File:这一部分就可以写入你要添加的附件，你通常要写入的是你创建的分支的url。下面的Description部分可以写入你对评审的简短描述。再往下的Content Type很明显是说所要添加的附件的类型，后面的那行英文告诉了你，什么时候应该勾选上path前面的选择框。Comment里头可以写一些感觉需要很多字数才能说清楚的事。这里有一个比较“隐晦”的地方，Flags底下有个inspection,后边跟着一个可选的按钮，当你提交评审的时候，需要把那里选成?，后边会出现一个可以写入内容的文本框，可以写入邮箱地址，你要让谁评审，就把谁的邮箱地址写到这里，如果想让多个人评审呢？那就写多个人的邮箱地址，中间用逗号分开。写了一长串，其实，我觉得关键问题是有时候你找不到这个页面，只要找到了这个页面，里面该写啥你肯定能看明白，重点是注意一下点选问号，写多个人的邮箱地址这个“隐晦”的地方。

5. 查看邮件确认你提交的评审是否通过

当你对bug提交完评审后，你所指定的查阅评审的人会收到bugzilla发的邮件，然后他会去检查你的工作成果，如果合格了，他就会对你提交的评审添加+，否则添加-。不管检查你工作成果的人给你的评审是通过与否，你都会收到一份由bugzilla服务器发给你的邮件。如果通过了，邮件内容中会有inspection+的字样，如果没通过，邮件中会有inspection-的字样，邮件很简单，所以这几个字还是很好找的。如果没有通过，那你肯定还需要继续你的工作，你肯定不愿意你的工作"烂尾"吧？如果通过了，那就可以去gitlab创建mergerequest了。

6. 去gitlab创建mergerequest

首先，在gitlab上找到你的分支所在的仓库，在这个仓库里就可以找到你新建的分支，在你新建的分支名后面就有+MergeRequest按钮，点此按钮，进入一个新的页面。当你进入这个界面的时候，title部分已经填入了你新创建的分支名称，这里不需要改动。Description部分可以写入一些对这个分支内容的描述，不过因为在以前提交说明里，已经有了比较详细的描述，所以这里通常也不需要写（除非你感觉有些话非说不可）。Assign To后边是个下拉列表，里面列出了跟你在一个团队中的人的姓名，从这里你就可以选择一个用户，指定为将要合并你的分支到主分支的那个人（通常就是你的组长）。后面的Source Branch和Target Branch都不需要改动，直接点击Submit new merge request进行提交，这就完成了mergeRequest的创建。

再随后的工作就是组长将你的分支合并到主分支上，如果是编写文档的工作，那到这里的时候工作流程就算结束了，但是如果是编译了软件包，那工作流程还没完。合并完编译过的软件包后，系统会自动集成新编译的软件包到以前的操作系统系统上，这时候会新出一张光盘，交给测试人员测试，如果测试通过，组长会将这个bug关掉，这时候你的工作流程才算正式结束了，如果测试出了问题，那就需要再去改进工作，直到正确为止。

3、尾声

写了这么多，终于介绍完了维护linx6.0.42.41操作系统的工作流程，如果你读到这里的时候，对这个工作流程在你的脑海中有了整体的印象，那这篇文档就达到了预期的目标；如果你读到这里的时候，仍然不知道怎么去展开维护linx6.0.42.41操作系统的工作，那我想说，不好意西，我浪费您的时间了！您要不再读一遍，或者想其他办法，总归要了解维护linx6.0.42.41操作系统的工作流程，要不然工作都没法展开。当你了解了整套工作流程后你会发现，所有的环节都在围绕一个目标展开，那就是实现了办公的自动化，你掌握了工作流程中的各项操作，会让你的工作轻松很多，团队的工作效率也会随之提升。但是当你不知道一些步骤的时候也不要懊恼，因为这里涉及到的只有知道与不知道的问题，所以，只要平时注意积累，记住步骤就好。 衷心感谢您的阅读。