论文部分内容阅读
摘要：对比传统的软件版本发布管理过程与容器化环境下的软件版本发布管理过程的不同，介绍如何在容器化环境下，做好软件版本发布。通过持续集成技术，基于容器化环境，完成代码的编译，发布docker镜像，部署到应用主机；结合TFS等工作流程工具，配合版本管理流程，实现测试环境及生产环境的版本发布管理。同时，对版本发布过程中的问题进行探讨。
关键词：容器化；版本发布；版本管理；持续集成
一、引 言
随着mesos、marathon、docker等容器化技术的发展和广泛应用，应用系统的发布、部署方式都有了很大变化。基于容器化进行代码发布，使软件代码版本发布管理流程与以往有所不同。
传统管理模式，开发并测试通过的代码，提交到配置管理工具，交由平台、运维人员编译部署，完成软件代码的发布。通过这种模式，实现应用系统的代码发布过程控制。
随着容器化技术的应用，开发部署模式发生了很大变化，从而带来了整个版本发布管理流程的变化和改善。
Docker是一个开源的应用容器引擎，开发人员可以将应用代码和依赖包，打包到一个容器内，然后将整个可执行程序发布到任何流行的Linux主机上，实现代码发布、部署。这个打包过程通过持续集成技术可以实现自动化版本发布。
二、以往代码版本发布管理模式
代码版本发布管理模式，根据项目规模，有很多种。大型项目中，有专门的版本发布管理流程，进行版本管理及发布控制。小型项目，较好的情况是，能够进行代码版本管理，但版本发布过程相对随意。
传统的版本发布流程为：根据版本发布计划，开发人员开发代码，提交到配置管理工具中的代码待测库中；平台人员拉取待测库的代码，根据开发人员提供的编译顺序要求，进行软件代码编译发布，将可执行程序发布到测试环境；测试人员在测试环境中，完成测试，测试通过后，代码进入待发布库；待版本计划中拟发布的全部需求，完成开发，通过测试，由配置管理员冻结待发布库，并获取待发布库的代码，交给平台、运维人员编译部署，实现最终的软件版本发布。这个过程中，大量的人工介入工作，另外，复杂的配置文件在配置过程中耗费大量时间和精力，甚至经常出现因为环境变量、配置文件发生的变化，导致测试环境已经测试通过的代码，部署到生产环境时，无法正常运行，再投入人力、精力，进行问题定位、解决。
这样的代码版本发布管理模式，能够实现应用代码的控制管理，发布正确的、完整的软件版本。主要存在的问题是，版本发布的动作较多，容易出现代码发布不完全、多套环境上运行情况不一致等问题。
三、容器化环境下的版本发布管理模式
前面谈到容器化环境下，使用Docker应用容器引擎，发布镜像，实现代码发布、部署。
这个过程，在管理流程描述上，与传统版本发布管理模式是一致的，代码提交配置库，完成测试，测试通过后，进行代码编译发布。
主要的变化在于，版本发布过程中，借助持续集成技术，结合TFS、svn等工作流程工具、配置管理工具，固定版本发布計划，基于容器化环境，完成代码的自动化拉取、编译和检查，发布Docker镜像，平台、运维人员非常方便的部署到应用主机，从而实现版本发布管理。
在项目实际工作中，可以采取的流程为：结合TFS工作流程工具，确定版本发布计划，开发人员根据版本发布计划完成代码开发，并将代码提交配置库后，置工作任务状态，触发持续集成工具；持续集成工具，自动下载已提交代码，根据工具中已配置、已识别的编译顺序，完成应用代码的编译，并发布镜像到镜像仓库，供测试及生产发布部署。在镜像生成后，测试人员可拉取镜像，在Docker容器内，完成代码测试，测试通过则镜像版本静止，测试不通过，重复代码修复、提交、持续集成的过程，直到测试通过。测试通过后的镜像，可直接用于平台、运维人员部署到生产环境Docker容器内。
以上版本发布管理工作，解决了传统模式下人工介入问题，解决了发布遗漏导致的测试环境和生产环境不一致问题，在实现软件代码版本发布工作上，更加有效、更加简化、更加完整。
容器化环境下的持续集成编译时，有两种策略可以选择，全部编译配置库分支下所有代码或只编译变动代码。另外，非常有必要在容器化环境下实施自动化编译检查。
容器化持续集成，编译结果稽核可以采取的处理方式为：每次编译前先执行make clean；然后make或者make release。make完成后，采用grep error、错误等，并排除合理的error信息。这种自动化检查方式简单，但不是很准确，而且一旦新开发带error的cpp或者.h，其中出现警告信息的话，就会出现编译报错终止，需要对出现的错误再修改规则。可以采取的优化措施为：make clean 之后也加入错误检查，检查相应文件是否删除；make或者make release编译某个目录的时候，通过检查文件，比如动态库或者可执行程序等是否生成，来判断编译结果的准确性。这些优化措施都需要整理出对应关系，这个对应关系是指定某个目录编译产生什么样的文件、清除什么样的文件。有些应用的动态库是带时间戳的、而且也不清除，比较复杂，自动化编译查错需要继续研究。但作为保证措施，大大降低了版本发布管理过程中，可能出现的代码发布遗漏风险。
四、遇到的问题及解决方案
无论是传统模式还是容器化模式，都会存在一定的问题，在容器化环境下的软件版本发布管理，也遇到一些技术及流程问题，通过实践，形成了解决方案。
刚开始进行容器化下的持续集成时，也出现过开发人员编译没有问题，但持续集成编译报错问题，这种现象一般都是由于开发人员和持续集成工具所用的编译环境存在差别，基于容器化解决的最根本的问题就是环境统一的问题。因此版本发布管理中，首先要统一代码编译发布的基础环境，其次统一维护。
采用docker镜像编译开发新增的组件、程序、配置等时需要通知开发人员，否则可能出现程序用的旧的组件、或者旧的静态库、旧的配置等问题。同时，反过来，开发人员进行代码开发时，注意事项、关联编译等版本发布关键信息也要通知持续集成平台。这些版本发布管理流程、角色职责的规定、改进，会提高版本发布工作的上下游协同，提高版本发布成功率。
五、结 论
容器化技术的发展，推动了版本发布管理流程的改进，更好的发挥了持续集成的作用，更加有效地提升了版本发布效率。
参考文献：
[1]邱晖 基于容器的持续集成和部署方法研究 [期刊论文]- 《广东通信技术》 ，2017（10）：62-66[S]
关键词：容器化；版本发布；版本管理；持续集成
一、引 言
随着mesos、marathon、docker等容器化技术的发展和广泛应用，应用系统的发布、部署方式都有了很大变化。基于容器化进行代码发布，使软件代码版本发布管理流程与以往有所不同。
传统管理模式，开发并测试通过的代码，提交到配置管理工具，交由平台、运维人员编译部署，完成软件代码的发布。通过这种模式，实现应用系统的代码发布过程控制。
随着容器化技术的应用，开发部署模式发生了很大变化，从而带来了整个版本发布管理流程的变化和改善。
Docker是一个开源的应用容器引擎，开发人员可以将应用代码和依赖包，打包到一个容器内，然后将整个可执行程序发布到任何流行的Linux主机上，实现代码发布、部署。这个打包过程通过持续集成技术可以实现自动化版本发布。
二、以往代码版本发布管理模式
代码版本发布管理模式，根据项目规模，有很多种。大型项目中，有专门的版本发布管理流程，进行版本管理及发布控制。小型项目，较好的情况是，能够进行代码版本管理，但版本发布过程相对随意。
传统的版本发布流程为：根据版本发布计划，开发人员开发代码，提交到配置管理工具中的代码待测库中；平台人员拉取待测库的代码，根据开发人员提供的编译顺序要求，进行软件代码编译发布，将可执行程序发布到测试环境；测试人员在测试环境中，完成测试，测试通过后，代码进入待发布库；待版本计划中拟发布的全部需求，完成开发，通过测试，由配置管理员冻结待发布库，并获取待发布库的代码，交给平台、运维人员编译部署，实现最终的软件版本发布。这个过程中，大量的人工介入工作，另外，复杂的配置文件在配置过程中耗费大量时间和精力，甚至经常出现因为环境变量、配置文件发生的变化，导致测试环境已经测试通过的代码，部署到生产环境时，无法正常运行，再投入人力、精力，进行问题定位、解决。
这样的代码版本发布管理模式，能够实现应用代码的控制管理，发布正确的、完整的软件版本。主要存在的问题是，版本发布的动作较多，容易出现代码发布不完全、多套环境上运行情况不一致等问题。
三、容器化环境下的版本发布管理模式
前面谈到容器化环境下，使用Docker应用容器引擎，发布镜像，实现代码发布、部署。
这个过程，在管理流程描述上，与传统版本发布管理模式是一致的，代码提交配置库，完成测试，测试通过后，进行代码编译发布。
主要的变化在于，版本发布过程中，借助持续集成技术，结合TFS、svn等工作流程工具、配置管理工具，固定版本发布計划，基于容器化环境，完成代码的自动化拉取、编译和检查，发布Docker镜像，平台、运维人员非常方便的部署到应用主机，从而实现版本发布管理。
在项目实际工作中，可以采取的流程为：结合TFS工作流程工具，确定版本发布计划，开发人员根据版本发布计划完成代码开发，并将代码提交配置库后，置工作任务状态，触发持续集成工具；持续集成工具，自动下载已提交代码，根据工具中已配置、已识别的编译顺序，完成应用代码的编译，并发布镜像到镜像仓库，供测试及生产发布部署。在镜像生成后，测试人员可拉取镜像，在Docker容器内，完成代码测试，测试通过则镜像版本静止，测试不通过，重复代码修复、提交、持续集成的过程，直到测试通过。测试通过后的镜像，可直接用于平台、运维人员部署到生产环境Docker容器内。
以上版本发布管理工作，解决了传统模式下人工介入问题，解决了发布遗漏导致的测试环境和生产环境不一致问题，在实现软件代码版本发布工作上，更加有效、更加简化、更加完整。
容器化环境下的持续集成编译时，有两种策略可以选择，全部编译配置库分支下所有代码或只编译变动代码。另外，非常有必要在容器化环境下实施自动化编译检查。
容器化持续集成，编译结果稽核可以采取的处理方式为：每次编译前先执行make clean；然后make或者make release。make完成后，采用grep error、错误等，并排除合理的error信息。这种自动化检查方式简单，但不是很准确，而且一旦新开发带error的cpp或者.h，其中出现警告信息的话，就会出现编译报错终止，需要对出现的错误再修改规则。可以采取的优化措施为：make clean 之后也加入错误检查，检查相应文件是否删除；make或者make release编译某个目录的时候，通过检查文件，比如动态库或者可执行程序等是否生成，来判断编译结果的准确性。这些优化措施都需要整理出对应关系，这个对应关系是指定某个目录编译产生什么样的文件、清除什么样的文件。有些应用的动态库是带时间戳的、而且也不清除，比较复杂，自动化编译查错需要继续研究。但作为保证措施，大大降低了版本发布管理过程中，可能出现的代码发布遗漏风险。
四、遇到的问题及解决方案
无论是传统模式还是容器化模式，都会存在一定的问题，在容器化环境下的软件版本发布管理，也遇到一些技术及流程问题，通过实践，形成了解决方案。
刚开始进行容器化下的持续集成时，也出现过开发人员编译没有问题，但持续集成编译报错问题，这种现象一般都是由于开发人员和持续集成工具所用的编译环境存在差别，基于容器化解决的最根本的问题就是环境统一的问题。因此版本发布管理中，首先要统一代码编译发布的基础环境，其次统一维护。
采用docker镜像编译开发新增的组件、程序、配置等时需要通知开发人员，否则可能出现程序用的旧的组件、或者旧的静态库、旧的配置等问题。同时，反过来，开发人员进行代码开发时，注意事项、关联编译等版本发布关键信息也要通知持续集成平台。这些版本发布管理流程、角色职责的规定、改进，会提高版本发布工作的上下游协同，提高版本发布成功率。
五、结 论
容器化技术的发展，推动了版本发布管理流程的改进，更好的发挥了持续集成的作用，更加有效地提升了版本发布效率。
参考文献：
[1]邱晖 基于容器的持续集成和部署方法研究 [期刊论文]- 《广东通信技术》 ，2017（10）：62-66[S]