实习番外篇：解决C语言使用Makefile无法实现更好的持续集成问题

工作中遇见的一个问题，提供项目源代码的情况下，希望对项目进行持续集成，达到一个C项目增量编译的效果。原本第一天是想通过模拟Makefile执行步骤来实现整个过程的，但是事实上发现整个Makefile显得无规律可寻，并且分布于项目的每个文件夹中，无法做到很好的控制。经过一段时间的讨论想出一个好办法，即将编译前的项目和编译后的项目进行对比，将项目中的编译过程中增加、删除和修改的文件进行记录，之后再根据实际情况对项目进行整体打包，这个便是整个过程中的总体思路。

我的工作步骤为：在项目执行之前对项目中的所有文件——从项目的根路径出发进行记录放在一个text1.txt文件中，而后项目执行完之后再次使用该方法将项目中所有文件记录于text2.txt之中。text1.txt与text2.txt两个文件记录的是项目中所有文件的绝对路径和文件内容的MD5值（MD5值后期优化思路：将绝对路径也放入文件内容之中，这样子相同内容的文件其MD5值也会不相同，更好的应用项目）。通过比对两个文件中的信息可以得出Makefile执行前后文件的增加、删除与修改情况，比对方法如下：

text1中有多行项目文件信息，第一列为项目中所有文件的绝对路径，第二列为相对应的文件MD5值；text2同理。

增加文件：当text2中出现了text1中所没有的文件时（仅仅通过比对增加的绝对路径就ok），那么我们认为该文件为执行Makefile后增加的文件，并将其记录于增加文件的记录之中；

删除文件：与增加文件恰好相反，当text1中出现了text2中没有的文件时（仅仅通过比对增加的绝对路径就ok），那么我们认为该文件为执行Makefile后删除的文件，并将其记录于删除文件的记录之中；

修改文件：修改文件是当text2中出现的路径如果在text1中也存在，如果二者的文件MD5值是相同的，我们认为是同一个文件，该文件是没有变化的；如果二者的文件MD5值是不同的，我们认为不是同一文件，即是修改文件。

因为项目最后的要求是将编译过程中的文件进行增量打包，所以我们要将增加文件和修改文件按照对应项目的相对路径放置于项目的文件夹中，我们可以直接按照记录进行操作即可。最后上传该打包文件时，增加部分的文件可以正常上传，修改文件本系统中是能够直接进行替换（如果无法替换就按照修改文件的路径先将所有修改文件删除，而后再统一上传即可）。对于上传文件初步的设想是读出路径并直接在云端执行shell脚本进行删除。

以上即为项目的总体思路，上述过程均通过python脚本实现。python脚本的调用及替换等操作为已有系统使用shell脚本进行调用，剩余部分工作为我的同事进行协作完成。

以上思想在具体执行过程中还遇见项目具体问题，部分已经解决，部分因为时间原因暂时使用硬编码的方式解决，二期项目将会通过配置文件的方式来解决；

问题一：项目执行过程中仅仅要求记录制定文件目录下的文件变化，对于剩余部分文件目录变化不关心

我们在得到增加和修改的文件路径信息之后，首先对其进行一个预处理。通过硬编码的方式将我们所需的路径筛选出来，而后再按照我们要求的步骤进行处理。

后期的优化方案为：通过类似于搜索引擎的Robots.txt协议的方式，将需要的目录和不需要的目录标明，同时选择默认目录的处理方法，最后通过Python脚本的逻辑实现来完成文件筛选操作

问题二：开发环境，测试环境及生产环境的环境变量配置是不同的，每次都需要单独上传，这个应该如何处理？

对于这部分要求，他们环境变量编译前后是不会发生变化的。我们需要在整个项目将增量取出后，再单独处理这部分文件，将其放置于文件夹之中。