Q&A Clarifications: Continuous Integration, Continuous Delivery, and What’s Next? #

Hello, I’m Zheng Ye.

The “Automation” module has come to an end, which is the most “technical” one among the four work principles and should be the most familiar topic for programmers.

I started by discussing the automation of software externally – workflows, allowing you to focus on writing good code. Then, I talked about the automation of software internally – software design, choosing the appropriate approach, not just seeking temporary satisfaction, and avoiding future pitfalls.

Since this is a topic that everyone is familiar with, students naturally have a lot of experiences to share and have seen different approaches from their own. They have raised various interesting questions.

In today’s Q&A, I have selected several interesting questions for everyone to further extend from the existing content.

Question 1: Can continuous delivery be further expanded? #

Classmate Yi mentioned:

In order to achieve effective delivery, it is also important for users to participate as early as possible. I think it is possible to extend the results obtained from the production environment and include users as an independent node. - From “32 | Continuous Delivery: Is Continuous Integration Enough?”

Classmates Xixifu and Kafka mentioned:

Continuous delivery can deliver the maximum value when the scope is not limited to software but can be further extended to operations. For example, by combining AB testing, the most effective operational strategy can be automatically selected to deliver the maximum value to users. - From “32 | Continuous Delivery: Is Continuous Integration Enough?”

The fact that these two classmates can come up with such ideas shows that they really understand continuous integration and continuous delivery, so they can extend and consider further expansion based on this foundation.

I have been emphasizing in this column that you should not confine yourself to the role of a programmer alone, but that you should understand the full lifecycle of software development. In the previous content, I discussed various methods of product development, such as MVP and user testing. If you only see yourself as someone who writes code, then understanding these concepts may not be very meaningful. However, if you want to put yourself in a larger context, then it is necessary to understand these concepts.

Returning to the question of the two classmates, if we define continuous integration as completing the task of writing code, then continuous delivery pushes this “completion” one step further by making it about deploying the code.

However, in the context of the entire software lifecycle, deployment is not the end point. Deploying the system is not the ultimate goal. So what is the ultimate goal?

Going back to the starting point of our thinking, why do we develop software? Because we want to solve a problem. But have we really solved the problem? In fact, we don’t know yet.

In the article “06 | Lean Startup: What to Do When Product Managers Are Not Reliable?”, I talked to you about the origins of product development. If we work in the Lean Startup mode, the purpose of building a product is to validate an idea. So how do we know if we have validated our idea? We need to collect various data as evidence.

Therefore, I have had the idea that Lean Startup is actually a form of continuous validation, validating the effectiveness of ideas and obtaining validated learning.

There are now several ways to obtain validation data, such as the AB test mentioned by classmates Xixifu and Kafka.

AB testing is a random experiment with two (or more) variants. It is often used in the design process of web or app interfaces, where two (or more) versions are created and different versions are randomly shown to different groups of users with the same characteristics. Data is collected to evaluate which version is better. Ideally, there should be only one variable for each test, because if there are multiple variables, you will not be able to determine which variable is responsible for the observed effects.

The concept of AB testing has a long history in other fields. In 2000, Google engineers were the first to apply it to software product testing, and now it has become a common working method for many product teams.

AB testing relies on collecting user data. In the article “09 | Can Your Work Be Measured with Numbers?”, I introduced how numbers can help us improve our work during the development process. In the field of product development, using numbers to communicate is actually more persuasive.

I once encountered a situation where a product manager in a trading platform product came up with a new order type, claiming that it would be more convenient for users and would improve capital utilization. If the programmers accepted this idea, it would mean making significant changes to the system.

I asked him a few questions: Firstly, have you ever recorded the usage of existing order types in the system? Secondly, have you looked into whether other platforms support this type of order?

The product manager was stumped. The answer to my first question was that besides the most basic order type, the usage of other order types was very low. Many supposedly optimized order types created in the past were actually used by very few people.

The answer to my second question was that only a few platforms supported similar concepts. In other words, although our idea was great in theory, the cost of educating users would be very high. Making such a big overhaul to the system for a potential advantage would be an investment with little return, not worth it!

Returning to our question, once you have decided to develop a certain product feature, the first thing to consider is how to collect user data. For frontend products, there are already many services available today, and it’s easy to embed a piece of code to collect data.

Frontend products are relatively easier because user behavior is more consistent. For backend data, although there are also various services available, most of them only provide capabilities for data collection and display. Some so-called standard capabilities are only about CPU, memory, JVM, and other basic infrastructure usage. For applications, the specific data to be collected still needs to be designed by the team themselves.

Having said all that, what I actually want to say is that although continuous validation is a good idea, it is not as well-supported as continuous integration and continuous delivery, which already have relatively complete systems. In order to achieve “continuous”, automation is necessary, and in order to achieve automation, standardized support is needed. Currently, this aspect is still in a state of “everyone is doing their own thing” without reaching the level of industry best practices.

In fact, the logic is quite simple: from starting with nothing to continuous integration, then to continuous delivery, and finally to continuous validation, most teams will drop out at each stage. Therefore, teams that can truly achieve continuous delivery are very rare, let alone continuous validation.

Question 2: What is the difference between Selenium and Cucumber? #

An anonymous student mentioned:

Teacher, is there any difference between Selenium and Cucumber? - ——"33 | How to do acceptance testing well?"

This is a question that many people often confuse. To help those who are unfamiliar with them understand, let me provide some background first.

Selenium is an open-source project that focuses on browser automation and is mainly used for testing web applications. It was originally developed by Jason Huggins in 2004 to address the challenges of testing web front-ends.

The reason it was named Selenium was mainly to satirize its competitor’s product developed by Mercury. As we know, Mercury is a toxic metal, while Selenium is a substance that can counteract the toxicity of Mercury. This is a humorous play on words by the programmers!

The rise of Cucumber coincided with the flourishing development of Ruby on Rails. As mentioned in previous content, Ruby on Rails is a web development framework that has changed industry perceptions. Therefore, Cucumber was initially mainly used for testing web applications, and Selenium happened to be a tool for manipulating browsers, creating a perfect match between the two.

As a result, you will see in many articles that Cucumber and Selenium appeared almost simultaneously, which is why many people find it a bit confusing to distinguish between the two.

Now that you understand this background, combined with what we have talked about before, it is not difficult to understand. Cucumber provides a layer of business description framework and requires its corresponding step implementations in order to manipulate the system under test. Selenium, on the other hand, is an excellent tool for defining steps in web application testing.

Question 3: How to learn IntelliJ IDEA? #

hua168 asks,

How should I learn IDEA? Should I learn by using its features, or should I first get a general idea and then delve into it when needed?- ——《30 | What does a good project automation look like?》

How should one learn a tool? In my experience, the best way is to use it. I haven’t specifically studied IntelliJ IDEA, but have been using it constantly. Whenever I encounter a problem, I search for the corresponding solution.

If I have put effort into anything in IDEA, it would be learning the keyboard shortcuts. Initially, my coding style involved using both the mouse and keyboard. To be honest, I didn’t think much of it at the time. However, after joining ThoughtWorks, I saw many people using keyboard shortcuts skillfully. It was not just about writing a line of code, but writing a whole piece of code. It was a moment of shock for me.

I thought I was already pretty good at coding, but someone completely surpasses you in something you are good at. In that instant, I felt like all those years of learning had been in vain. This feeling arose again when I saw others performing small refactorings.

After realizing the difference, the only thing I could do was practice secretly. Luckily, both keyboard shortcuts and refactorings can be practiced individually. By spending some time, you can reach a certain level of proficiency. Later on, people watching me write code would have a similar feeling, and I would console them by saying, “Don’t worry, just spend some time practicing.”

In fact, there are also some auxiliary methods that can help us practice. For example, we provide new employees with shortcut cards for IntelliJ IDEA, which they can refer to during breaks from coding. Another example is a plugin for IntelliJ IDEA called Key Promoter X. If you perform an operation with the mouse, it will remind you of the shortcut, helping you remember it. At one point, I had practiced to the point where I could completely map out the keys someone was pressing in my mind just by watching them write code.

Coding is a craft, and to refine this craft, we need to see how the experts work in order to avoid complacency. If you don’t have such people around you, it’s a good idea to search for some videos online and see how the experts write code. This way, you can identify the gaps and continuously improve.

Alright, that’s all for today’s Q&A. How do you feel about these questions? Feel free to share your thoughts in the comments.

Thank you for reading, and if you found this article helpful, please feel free to share it with your friends.