持续集成之入门
近期工作非常忙碌，团队人员也不断的扩充，原本作为小创业公司很久没注意的一些自动化基础设施一直没有做或者是做了没有完善，其中很重要的一部分是关于持续集成或者说是自动化部署和编译项目所需要的代码。但是随着人员的增多和项目的复杂性的增强，反倒越来越觉得工欲善其事必先利其器这个道理一点都没有错，因此一点点的进行抽空在做关于持续集成的基础架构，也只有进过痛苦才能换来更加高效的开发工作。
按照个人的学习习惯，还是先在这里了解下关于持续集成的概念。引用来自百度百科的话”持续集成是一种软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽早地发现集成错误。“ 我们可以发现持续集成和这些年来的所谓的DevOps运动，敏捷开发都有关系或者说是基础后者表现形式吧。
软件的发布编译其实通常包括很多环节也却分了诸如生产环境、测试环境，预生产环境、开发环境等多套环境，传统的人员涉及开发、测试以及运维人员相互需要协助，比如开发编译，运维配置环境手工或者运用某些运维工具上线部署测试人员参与测试这显然无法满足敏捷开发和多次发布的需求。
持续集成的大致流程应该是：
1.日常开发人员开发调试代码，提交代码到个人的branch上或者到开发分支上
2.需要测试部署时，开发人员间合并自己的代码这里使用git并将代码推到用于测试的tree上
3.此时有持续集成类的服务器比如Jenkins或者gitlab代码的 CI/CD工具自动编译代码，并将编译结果通知相应开发人员
4.代码编译成功时候讲代码通过脚本或者其他工具（比如RPM包、Docker镜像）发布到测试环境
5.测试人员进行测试，有条件的公司可以进行自动化测试或者回归测试，可以将测试服务器、测试工具、Mock工具和持续集成服务器结合并生成测结果反馈给开发人员
6.改进迭代1-5的工程
7.当测试无误确认发布时合并分支到发布的tree，可以通过不同源码管理开发策略进行，不如合并到master分支，执行3和4的过程，进行生产服务器远程代码备份和发布流程。
8.反复循环迭代开发
实际上对于我们公司来说主要的持续集成需求目前来自Java项目和.net项目以及前端vue或者React的框架。因此选用Jenkis做为持续集成工具，Docker为最终发布结果进行发布。后面其他文章会介绍这些。
本文为Lokie.Wang原创文章,转载无需和我联系,但请注明来自lokie博客http://lokie.wang
- 上一篇： Linux端口号和PID互相查询
- 下一篇： 使用curl 命令模拟POST/GET请求
- 最新评论
- 总共0条评论
