Agile question: continuous integration

Q: My products are telecommunications-level devices. Hundreds of people are divided into dozens of project groups for development. How can I integrate them?

A: What you want to do is actually not related to technology. More is the management work, that is, developing your product-level integration policies.

This involves requirement analysis and release plans (dependency management, value and risk identification), development methods (top-down or bottom-up, Horizontal layering or vertical features ),
Integration granularity Division (integration of complete features or API Integration), integration interval plan, version control policies, especially important integration test/verification policies, and even your determination.

Any integration strategy may encounter difficulties during implementation, such as the delay in obtaining a version that can be successfully integrated. In this case, you need to find out the reason and have the right or corresponding measures to ask the entire team to stop,
As the first priority task to repair. and let the entire team know the losses caused by progress stagnation. the intention of doing so is to emphasize the importance of integration. Therefore, every project team should give priority to integration with other components during development,
This facilitates better communication and feedback, reduces the number of integration failures, and reduces the integration interval.

To some extent, this will bring a positive impact to your design. for example, for easier integration, loosely coupled protocols/messages or standard data formats are used between modules to replace tightly coupled API calls.
Define extensible interfaces to isolate the impact of modifications...

Use integration to drive your development process.

 

Q: The project team works on their respective branches. It takes several days to merge the versions each time. How can we achieve continuous integration?

A: Change the branch policy and use the same branch for integration at any time. For more information, see <Configuration Management Mode>

 

Q: It takes dozens of hours to build a build, including compiling links and testing. How can we integrate the build?

A: Actually, it is a speed issue. There are many potential optimization measures.

1. Optimize the source file dependency. Adjust the design after this adjustment.

2. Optimize build scripts

3. Optimize test cases to run together in a test environment

4. Test cases are classified to give priority to use cases with high value and fast speed. The test interval with low value and time consumption can be enlarged.

5. Distributed build, using software such as cruise or incredibuild.

6. Use high-performance hosts

 

Q: How to integrate hardware dependencies, especially embedded systems?

A: Ideally, the product code runs on a real embedded device, and the test results can be reported to the CI tool running on the PC.

Many of our projects have already achieved this, and the method is not difficult:

1. Upload the compiled code to the device using the methods supported by the device (such as FTP)

2. Send a command to the device to load the new Code (TCP or serial port)

3. Run the test case: You can run the test case on a PC and interact with the device through the network (TCP or serial port) to assert its behavior, or directly run it on the device, and then retrieve the test result through the network.

4. If the hardware is not available, use the simulation mode device.

 

Q: there is a new commit before the build ends. Do I have to wait until the previous build ends before the new build starts?

A: Most of the Ci tools you use are like this. however, in CI tools that support distributed building, another machine can be used to run the new build immediately. This is a possible feature,
If you know which tool implements it, please let me know.

The argument for this feature is that once the build fails, it is not easy to tell who submitted it, but this assumption is not true for two reasons:

1. Most CI tools are based on the round-robin mechanism, and there will always be one build containing multiple submissions

2. An agile team that has strict submission discipline and a sense of responsibility and regards CI as the top priority will run and build locally before submission. The probability of failure to build on the CI server is not high.

 

Q: Our products need to support a variety of operating systems. How does CI do?

A: Most CI servers can run on a variety of operating systems. The difference is that they are managed separately (built on a single machine) or uniformly managed (Distributed build ).

 

Q: Does each team need to run the CI integration environment on their own development machines?

A: You do not need to run the CI environment. You only need to run the build script that runs in the CI environment. Using the same build script as the Ci for local build will reduce the probability of Ci failure, see <publish
With a publisher
>.

 

Q: Do I have to know CI knowledge for every team?

A: The CI tool is actually very simple. More importantly, it is the integration strategy of the entire team.

 

Q: If the test goes first, how can I handle the test that is written in advance?

A: Another constraint of test first is to minimize the number of steps possible. Basically, you should not submit it before passing the test.

 

Q: But the automated integration test written by our testers in advance fails at the beginning. It is only gradually passed with the development. What should we do?

A: This is basically your test management strategy. A simple solution is to separate the testing that is doomed to failure and the testing that has implemented the corresponding functions. As the features continue to be completed, gradually move the test.

Automated testing tools support using tags to control whether to ignore or skip certain tests during runtime.

 

Q: The CI vision is good, but it is impossible for us here. Our products require a complex runtime environment and manual intervention. How can we test it?

A: I don't know what the complexity you are talking about is, how the manual intervention is, but this is indeed a common issue. Are there several real situations. we usually analyze specific problems,
However, there are several general principles:

1. Design, separate the core business logic from the external interface, and try to make the business logic environment irrelevant

2. Automation: Find appropriate automated testing tools and develop them as needed

3. Build a real running environment as much as possible

Integration relies heavily on your testing strategy and automation.

 

Q: You said that integration depends on the test policy and automation level. Can an integration without testing be regarded as integration?

A: Any integration effort is worthy of recognition, even if it is just continuous compilation. In fact, for companies that have to maintain large legacy systems all the year round, even if they only need continuous compilation,
It is of great value to ensure that compilation can be passed every day. Of course, we need to integrate as much automated verification work as possible.

The CI community has recently launched an attack for commercial purposes,
1
,

2
The tone is to despise the bad taste/anti-pattern of Ci continuous compilation. in fact, no one thinks that the core of continuous integration is continuous compilation. We respect any integration efforts and there is always the first step in everything.

 

Q: Is integration and testing available after integration?

A: It depends on how you define availability. confidence comes from a comprehensive test.

 

Q: I heard that CI environment configuration is quite troublesome. Is there any simple tool?

A: The software industry is not China Telecom, and its competition is fierce and cruel. If a tool is difficult to configure, it would have been simpler to replace it. Download and try it out, and then cooperate with the search engine,
You will certainly find the right tool within one day. If not, it is a chance and you can create a better one.

 

Q: I still have no idea about the CI tool. How does it know where to get the code? How do I know if there are any updates? How to get the code? How to compile? How do I know what tests to run? How can I know that the success failed?

A: The clients of the version control system are both available tools and provide public German protocols or interactive interfaces. This is no problem. As for compilation and testing, CI tools do not have to be known,
Although many tools can automatically identify your source code and test according to certain conventions, in fact, CI tools only faithfully run your configuration behavior, usually a script you write,
Therefore, it is up to you to specify how to compile and test. As for success or failure, CI follows the operating system convention and returns 0 success, not 0 failure.

 

Q: Our version control system is clearcase. Does your CI tool support it?

A: No. Change to subversion.

1. Clearcase slow

2. Expensive clearcase

3. Hard to use clearcase

4. Clearcase is too pessimistic. You have no temper

 

Q: How can we reduce the chance of failed CI building?

A: This is actually a best practice. For example, for products that need to run on multiple operating systems,
Different developers in the project team should use different target platform development as much as possible, so as to capture platform errors while building locally. For CI tool CC best practices, refer to http://blog.csdn.net/gongflow

 

Q: We work on legacy projects and face all the problems mentioned above: Compilation speed, environment dependency, progress dependency of multiple project teams, branch merge, and even version systems use clearcase,
I always feel that what you are talking about is false. It may not be able to improve the status quo.

A: This is a question of the input-output ratio (how long your project will be maintained, how much profit it will bring, and how much effort it will be worth to improve the value). It is also a question of value (it is a matter of laissez-faire, until it perish naturally,
Or gradually improve and see to what extent it can be changed ). I suggest you try it. Start with the simplest and less demanding environment and gradually expand the scope. all software will be deprecated, and people will die,
The meaning is to keep trying to see what will happen. If you know it is not worth it, you can leave some time to try other things.