[College] attention Geeks - Get more content
In the absence of application of continuous integration, the traditional development model is divided into modules outset of the project, and then wait for all of the code is developed, tested and then integrated into together.
With the development of software technology, various software flourishing, the software is also larger, more complex software requirements.
Software can not simply be developed by way of dividing module requires internal project cooperate with each other, the drawbacks of this traditional division module model has become increasingly evident:
-
As many bug existed early in the project, the final integration when it found the problem, developers need to spend a lot of time in the integration phase to find the root cause of the bug.
-
Software complexity, source of the problem is difficult to locate, and even had to adjust the underlying architecture of the situation appears particularly insecticides meeting at this stage, the content of the meeting basically discussed is how the bug, often end up become the person in charge of the different modules pass the buck to each other.
Therefore, in order to quickly find errors and solve problems, reduce slipstreaming difficulty, save manpower, the team more and more inclined continuous integration development model. But only the whole team really work in accordance with the continuous integration of the discipline, this team really be "owned" by continuous integration.
So today limit the torture to:
1, do you think, what continuous integration discipline?
2, how your team compliance with these kind of discipline?
In their daily work, continuous integration of the ground rules the following main points:
-
Not the backlog of code, small step to submit, submit frequently, frequently merge code;
-
When building or deployment fails CI, immediately repair, if not resolved, that rolled back immediately;
-
Have a sense of responsibility, who wrote, who is responsible;
-
The need for unit testing and code needs through self-test and static analysis tools.
Of course, slightly higher-order rules, but also include:
-
All code is contained in the continuous integration, including the deployment scripts, test scripts;
-
If each service has its own CI pipeline, when the CI build fails, others can submit new code at any time. On the contrary, everyone will need to submit code to stop until the repair is complete;
-
Update the design thinking, continuous integration mode under new requirements need to continuously optimize the software architecture of the software architecture and design.
For the above rules, how compliance with the members of the group do?
According to group members reaction, most of the group members as well as their own team can do with the sense of responsibility frequently submitted directly responsible for their own code, but in terms of problem solving, long used in the repair cycle.
在单元测试上，存在只是为了达成覆盖率而作单元测试的现象，且对单元测试的要求是只要能通过就好，碰到紧急的任务也会破坏单元测试，导致项目的单元测试状态是红色，事后再补充进去。
可见虽然规则虽十分明确，但由于种种因素，团队在工作时都会灵活遵守纪律与规则，使得工作更加高效。
持续集成的好处是十分显而易见的：
-
快速发现错误，每完成一点更新，就集成到主干，可以快速发现错误，定位错误也比较容易；
-
防止分支大幅偏离主干，如果不是经常集成，主干又在不断更新，会导致以后集成的难度变大，甚至难以集成；
-
更快速的发布更新，持续集成可以帮助团队更快速、更积极的发布程序和更新程序。在发布时可自动完成大量重复的工作、节省人力。
既然好处这么多，那好用的 CI 工具有没有推荐呢？这里可以关注一下 gitlab，它是一个 DevOps 平台，runner 配置很灵活强大，且它支持上下游 pipeline。发展到现在，gitlab 已经是repository 、issue tracker 、kanban 、docker registry 的集合体了。
我们还发现了持续集成带来的影响：出现个人只负责个人模块的问题。
▲【极限编程中国 | 实践者】成员发言
因为持续集成每个人负责的部分都被明确划分 ，出现问题需要修复时，除了当事人，团队中的其他人一般都不会替他修复。
其实这从根本上来讲是制度导致的问题。直接和绩效挂钩，考核的是个人的工作。因此，解决此类问题的方法无非便是更改制度，或自身注重代码质量，重视测试了。
本期内容整合自【极限编程中国 | 实践者】
内容贡献者：
如果你也想加入讨论，迅速成长
欢迎加入我们
立即扫描下方二维码限时免费加入【极限编程中国 | 实践者】微信群
和前ThoughtWorks总监咨询师熊节实践敏捷开发