The Importance of Continuous Integration in Modern Application Development

Continuous Integration is also known as CI, is the foundation of modern software development technology. This article discusses the current problems in the software development process, explains the concept of continuous integration, continuous integration of servers, and finally discusses why we need continuous integration to solve these problems.

Current Scenario of Software Development Process and its Problems

Before applying continuous integration, the traditional development model is this:

• At the beginning of the project, the modules are first divided and the modules are assigned to the corresponding developers.
• The developer develops a module to perform unit testing;
• After all the modules have been developed, all the code is integrated by the project manager;
• The integrated project is deployed by the project manager to the test server and submitted to the tester for integration testing;
• Bug in the process of testing brings up the problem record in the Bug list;
• The project manager assigns a bug to the corresponding responsible person to make changes;
• After the modification is completed, the project manager integrates the project again and deploys it to the test server;
• The tester performs regression testing in the next integration test;
• After passing through, deploy to the production environment;
• If the test does not pass, repeat the above “Assign Bug -> Modify Bug -> Integration Code -> Deploy to Test Server -> Integration Test” work.

The following problems may occur during this process:

1. The Bug is Always Found at the End

With the development of software technology, the scale of software is also expanding, and the software requirements are becoming more and more complex. Software can’t be developed simply by dividing modules. It is often necessary to cooperate with each other within the project, and there are certain dependencies between modules. So the bugs that existed in the early days are often discovered at the time of final integration.

2. The later the project, the harder the problem is solved

Many developers need to spend a lot of time in the integration phase to find the root cause of bugs. With the complexity of the software, the root cause of the problem is difficult to locate. And we all know that the longer the interval, the higher the cost of bug fixes, because even the developers themselves forget what ghost code they wrote, and they have to read the code and understand the code from scratch.

3. Software delivery timing cannot be guaranteed

It’s because we can’t fix bugs in time, or we can’t fix bugs in the early days, which makes the whole cycle of fixing bugs longer. Regardless, we cannot deliver software that knows that there are bugs.
Moreover, a large number of workloads that were not estimated in the previous period have resulted developers have had to spend a lot of time looking for bugs; testers are constantly required to perform regression testing; project managers have to be tired of the integration of damn code. Deploying these repetitive tasks ultimately leading to a prolonged cycle of the entire project and a delay in delivery time.

4. Programs often need to be changed

In some projects, programs often need to be changed, especially for agile development practitioners. Since the product manager is often the best prototype in the process of communicating with the customer, the software will be used as a prototype as a tool for communicating with customers. Of course, what customers want most is of course that the customer’s ideas can be immediately reflected in the prototype, which will cause the program to be modified frequently. Then it means that “Assign Bug -> Modify Bug -> Integration Code -> Deploy to Test Server -> Integration Test” work is invisible and exploding.

5. Invalid wait for more

It is possible to develop a module that integrates with others; the tester is waiting for the developer to fix the bug; the product manager is waiting for the new version to go live to give the client a demo; the project manager is waiting for someone else to submit the code. No matter what, waiting means inefficient.

6. User satisfaction is low

The users here are broad and can refer to the final customer, product manager, company leader, tester, and possibly the developer himself. If you think about it, the project that was originally completed in three months has been extended to nine months or even one year. Can the user be satisfied? Product managers and company leaders often need to take the project as a prototype for the demonstration. The result tells me that there are still many bugs that are not solved before the demonstration. The project cannot be accessed because it cannot be accessed. This is why people feel sorry for it.

Continuous Integration, Continuous Integration Server Concept

Well, in the problems discussed above, we found that some work is unavoidable, such as testing work, modifying programs, integrating work, and deploying work. But in fact, in the entire workflow, there is room for optimization. For example, can the work of integration testing be done in advance? Can there be automated means to replace testing, integration, and deployment? Around these, the software industry’s masters put forward the “continuous integration” slogan.

1. What is a continuous integration, continuous integration server

In software engineering, continuous integration (CI) refers to the practice of merging all developer working copies into the trunk multiple times a day. Grady Booch first named and proposed the concept of CI in the 1991 Booch method, although at the time he did not advocate multiple integrations every day. XP (Extreme Programming ) adopts the concept of CI and advocates integration more than once a day.
A continuous integration server is a tool that can use automated means to liberate people’s hands and achieve continuous integration of projects. The software that comes with it is TeamCity, Jenkins, Go, etc.

2. What is the “continuation”?

There is no clear definition of how many times a day needs to be integrated. Generally, a certain frequency is set according to the actual needs of the project, and it may be several times, and maybe dozens of times. You can set the code to trigger the integration, or set a fixed time period for integration, or you can manually click on the integrated button to “one-click integration.”

3. Continuously integrated workflow

• When you begin to change the code, the developer gets a copy of the current codebase from a codebase (such as SVN, Git, and so on).
• When other developers submit the changed code to the code base, the copy will gradually stop reflecting the code in the code base. The longer the code branch remains checked out, the greater the risk of multiple integration conflicts and failures when the developer branch is reintegrated into the mainline.
• When developers submit code to the codebase, they must first update their code to reflect the latest changes in the codebase.
• When the repository is different from the developer’s copy, they must take the time to deal with the conflict first.

The Benefits of Continuous Integration

1. Liberated repetitive labour

Automated deployment can free up repetitive work such as integration, testing, deployment, and the frequency of machine integration can be significantly higher than manual.

2. Fix problems faster

Because of the continuous integration of earlier changes, the earlier entry into the test, the problem can be detected earlier, and the cost of solving the problem is significantly reduced.

3. Deliver results faster

Early integration and early testing reduce the chances of defects remaining in the deployment process. In some cases, finding errors earlier will also reduce the amount of work required to resolve the error.
If the integration server finds errors during the build process of the code, you can send an email or SMS to the developer for repair.
If the integration server finds that a problem with the current version is not available during the deployment process, the integration server will roll back the deployment to the previous version. There will always be a version available on the server.

4. Reduce manual errors

One of the biggest differences between man and machine is that in repetitive actions, people are prone to making mistakes, and the chances of a machine making mistakes are almost zero. So, when we set up the integration server, the future will be handed over to the integration server.

5. Reduced waiting time

Continuous integration reduces the time between application development, integration, testing, and deployment, which in turn reduces the waiting time that can occur in the middle. Continuous integration means that development, integration, testing, and deployment continue.

6. Higher product quality

Integration servers often provide features such as Code review and code quality detection. If the code is not standardized or there is an error, it will be identified, and emails, SMS messages, etc. can be set to alert. Developers can continue to improve their programming skills through Code review.

Continuous Integration Best Practices

1. Frequently check out the code

In order to minimize the difference between your local copy and the version in the codebase, it is recommended to check the code frequently. Sometimes code conflicts are inevitable, but minimal differentiation is the easiest to solve. Moreover, the sooner the problem is discovered, the lower the cost of resolution.

2. Submit code frequently

This is similar to the principle of Article 1. Frequently submitting code can minimize the difference between other people’s checked-out copies and versions in the code base.

3. Reduce branches and return to the trunk

Although code management tools support the concept of branching, they should be minimized. Assuming multiple branches are parallel, integration should be integrated into the backbone as early as possible, rather than maintaining multiple versions of the software at the same time. The trunk is a working version of software development.

4. Use automated builds

Automated builds can be done using Maven, Ant, etc. These tools can help you automate testing during the build process. The premise is that you have to write unit test cases, such as JUnit.

5. Submit a Self-test

Before submitting a job, each programmer must integrate all the code locally, do a complete build and run, and pass all unit tests. This reduces the risk of integration testing failing to build on the integration server.

6. The current state is visible to everyone

The integration server finds problems during the continuous integration process and should be able to send alerts to the relevant stakeholders. At the same time, you can also set a large-screen display on the wall and other eye-catching positions, and display the status of the integrated server on the big screen in real time, which is convenient for reminding the team members to “hurry back to solve the problem”!

Challenges that continuous integration may face

1. The team members ideological conflicts

• Unable to accept new things: In any case, there are still many people who seek stability. There are always people who think that old technology representatives are stable, and new things often bring problems.
• I don’t think there is much work for manual integration: not all people are involved in the entire continuous integration process, so there is no way to recognize the whole picture.

In response to this problem, it can be improved by setting up a certain continuous integration technology training and presentation.

2. Management’s conflict

• Continuous integration of training requires investment, no money.
• Continuous integration of the server to increase hardware and software costs, no money.
• Developers have received such a high salary, and it is okay to work more and overtime.

In this regard, it is possible to estimate both the cost of the developer and the cost of the continuous integration of the inputs (software and hardware).

3. Complex production environment

• For example, the deployment environment of the deployment is in the government external network, and cannot be directly accessed from the Internet.

At present, this is the most troublesome and still under study. The initial idea is to open a whitelist of government external networks and set up a separate channel for the continuous integration server. Just thinking, not verified.
Of course, considering the actual work, you can continue to deploy the software to your company’s demo server, so at least solve the prototype problem used by the customer and product manager. After all, the software that customers actually use can be moderately relaxed on the frequency of updates.
Source: IAMWIRE
To Read Our Daily News Updates, Please visit Inventiva or Subscribe Our Newsletter & Push.