FAQs: Continuous Integration, a common thread running through many practices #
The “Communication and Feedback” module has come to a close, and in this module, we have brought ourselves closer to the real world.
On one hand, we emphasize proactive communication, effectively conveying our own information. On the other hand, we also value feedback, allowing information from the real world to return to us. Students have shared many experiences and raised several questions.
In today’s FAQs, I have chosen several excellent questions to expand on the previous explanations from different perspectives.
Question 1: Will poor unit testing affect the effectiveness of CI? #
Yi mentioned that
If unit testing is not done well or does not meet the A-TRIP criteria, will the effectiveness of CI be significantly reduced? - ——《24 | Why can’t your company do continuous integration well?》
This is a very good question that addresses the relationship between various practices. We have spent two lessons introducing continuous integration, why it should be done, and how to do it well.
In the automation module, we will continue to expand on this basis and introduce continuous delivery. These topics are described from an operational perspective and provide a detailed description of individual practices.
Taking this opportunity to answer the question, I’d like to add another dimension and discuss the relationship between practices.
The value of continuous integration lies in its ability to link various practices together. In other words, to truly do continuous integration well, many peripheral practices need to be done well.
Let’s talk about some of these practices specifically. But please remember what we have mentioned before, the key to good continuous integration is fast feedback.
For example, to do CI well, you need to have a stable development branch, so it’s best to use the main development branch approach. If you want to use the main branch development approach effectively, it’s best to make frequent commits. To make frequent commits, your tasks need to be small enough to be completed quickly. To break down tasks into small enough pieces, you need to have a good understanding of task decomposition. If you want to develop multiple features on one branch, you need to use feature toggle or branch by abstraction.
There are many opportunities to go wrong on this path. For example, if you choose the branch development model, the merging speed will not be too fast, and if feedback is not fast, the effectiveness of CI will be reduced. Furthermore, if you cannot make frequent commits, the time cycle for merging code will be longer. Once the time cycle for merging code becomes longer, people will tend to do less troublesome tasks, further reducing the frequency of commits, thus beginning a vicious cycle.
Similarly, even if you understand the above principles, without understanding task decomposition, you won’t be able to achieve frequent commits effectively. And parallel development of multiple features will naturally lead you to consider using a multi-branch model.
Let’s look at another aspect, which is testing as mentioned in this question.
To do CI well, you need to have something that is testable. The simplest things that are testable are compilation and code style checks, and these checks can be unconditionally included in the build script. But more importantly, the checks should come from testing, and to do CI well, we need a safety net of tests.
What does having a test safety net mean? It means that your tests should provide you with sufficient protection, which also means that you need to have enough tests. In more technical terms, this means having a sufficiently high test coverage.
If the test coverage is not sufficient, even if you submit code and pass CI, you will still lack confidence in your code, which will reduce the position of CI in your mind.
If you want to have a high test coverage, you need to write more unit tests. We have discussed the testing pyramid before, and because the upper-level tests are more cumbersome, you won’t write too many of them. Moreover, many boundary conditions cannot be covered by the upper-level tests. Therefore, after the initial rapid improvement, the test coverage will not increase significantly. To increase the test coverage, the only way is to write more unit tests.
To write more unit tests, you need to write code that can be tested, and to write code that can be tested, you need to understand software design and decouple the code between systems.
From the analysis above, you can see that to do continuous integration well and fully leverage its value, there is still a lot of work to be done. But please don’t be discouraged, in fact, when I consult with teams, many of them start by focusing on continuous integration and then improve other aspects that are not well done around it.
This is a “starting with the end in mind” approach. Locking in the goal is to do continuous integration well, and then improving other aspects that are not well done around this goal. For example, if there were multiple branches before, fix one main branch first, and then gradually change the development habits of everyone to enter a single-branch development state.
Another example is if there were no tests before, start by adding a minimum test coverage to the CI, and then improve it regularly. For example, the coverage could be 10% in the first week and 20% in the second week. In this way, step by step, the development team can develop new things while adding tests to existing code. When the coverage reaches a certain level and it becomes difficult to improve, the team can consider how to improve the design.
Therefore, as a separate practice, CI itself is quite simple, but it can become the guiding principle to help the team continuously improve its development process.
Question 2: What should I do if the boss participates in the retrospective but no one is willing to speak the truth? #
Grass10happy mentioned:
Is it best to hold retrospectives internally within the team? Every time the boss participates in the retrospective, it seems like no one speaks the truth. - Article 25: What should we do when problems keep occurring during development?
Thank you, Grass10happy, for bringing up this question, which allows me to address a part that I had omitted due to space constraints.
The purpose of a retrospective is to facilitate improvement. It is not just about involving everyone; more importantly, it is about enabling team members to speak openly and expose problems. The precondition for improvement is to expose problems.
In my article “Article 27: Expose Problems As Early As Possible: Why Are You Always Blamed?”, I discussed how, for many people, the willingness to expose problems is a psychological issue. You will find that chatting among colleagues is generally stress-free, and you can freely discuss various problems. However, as soon as a leader is present, many concerns arise.
Therefore, the question becomes how can we create an environment where everyone feels comfortable enough to expose problems? One way is to establish a safe environment.
How can we establish a safe environment? For a standard retrospective meeting, the first step should be a safety check.
Begin by having everyone vote, and the simplest way to do this is by rating the current environment. If you feel comfortable speaking freely, give a score of 1. If you feel it’s okay, give a score of 0. If you feel uncomfortable expressing yourself—for example, if you see the presence of the leader and believe certain issues are not suitable for feedback—give a score of -1.
Each participant casts their vote. Then, based on the voting results, the moderator decides whether to proceed with the retrospective meeting. For example, if someone voted -1, then the meeting cannot continue.
If the meeting can proceed, it’s great. But in the event that it cannot, there can be multiple solutions. For example, ask the person with the highest-ranking position in the room, which might be the boss, to leave. The boss may feel unhappy about it, but in this process, everyone is following the rules, and there is no preferential treatment for anyone.
After the boss leaves, we can then conduct another round of voting to determine if the environment has become safe. Repeat this process, possibly several rounds of voting, until everyone feels safe.
Of course, it is also possible to go through multiple rounds where someone still feels unsafe. In this case, the best option may be to cancel today’s retrospective meeting and start anew at a different time and place. The project leader then needs to privately address the team’s concerns regarding psychological safety.
After the safety check, we can proceed to the formal part of the retrospective meeting. The specific content has already been discussed in the main body of the article, so I will not elaborate on it here.
Question 3: Is the domestic technology information lagging behind? #
One day mentioned,
Teacher, can you introduce more websites related to technology, the development and observation of new technologies, or technical summaries? Most of the technology in the country is somewhat lagging behind. - ——《23 | Visualization: A More Intuitive Way of Communication》
This question makes me feel like I’m back to many years ago. When I first started in this industry, it was indeed necessary to read more English websites to learn new knowledge. At that time, the speed of information dissemination was not fast, and there were not many Chinese technology websites.
However, today, it’s obviously not the case anymore. If you just want to get the latest technology information, I have introduced InfoQ and the Technology Radar in the article 《23 | Visualization: A More Intuitive Way of Communication》, which already contain abundant information. As long as you browse a few more websites and follow a few public accounts, various information will be delivered to you.
So, you don’t need to worry about missing out on new technologies at all. On the contrary, there is an overwhelming amount of information that needs to be filtered.
The real lagging behind for domestic programmers is not in terms of information, but in terms of mindset.
Many of the topics I discuss are related to software engineering. Based on my understanding of programmers both domestically and abroad, programmers in developed countries have a better grasp of these topics compared to domestic programmers.
The average level of domestic programmers mostly stays at the understanding of implementing a functionality, while programmers in developed countries are much more professional. Therefore, in terms of professional skills, there is still a lot of room for improvement for domestic programmers.
In economics, there is a “law of diminishing marginal utility”, which states that as the total amount of a certain item in your hand increases, the utility gained from an additional unit of that item usually decreases.
When your technical knowledge has accumulated to a certain level, it becomes difficult to achieve significant improvement by using the same learning methods as before. This is the reason why many people complain that the IT industry is difficult to thrive in.
At the same time, this is also the original intention of me starting this column, hoping to provide you with different perspectives and new motivations for advancement.
Alright, that’s all for today’s Q&A. I would like to invite you to share how you understand these questions. Please feel free to write down your thoughts in the comments section.
Thank you for reading and if you found this article helpful, feel free to share it with your friends.