Continuous Integration is also known as CI. It is the foundation of modern software development technology. This article discusses the current problems in the software development process and explains the concept of continuous integration, continuous integration of servers, and finally discusses why we need continuous integration to solve these problems.
Before applying continuous integration, the traditional development model looks like:
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.
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.
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.
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.
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.
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.
Well, 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.
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.
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.”
Automated deployment can free up repetitive work such as integration, testing, deployment, and the frequency of machine integration can be significantly higher than manual.
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.
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.
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.
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.
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.
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.
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 codebase.
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.
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.
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.
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”!
In response to this problem, it can be improved by setting up a certain continuous integration technology training and presentation.
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).
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.
SPEC INDIA, as your single stop IT partner has been successfully implementing a bouquet of diverse solutions and services all over the globe, proving its mettle as an ISO 9001:2015 certified IT solutions organization. With efficient project management practices, international standards to comply, flexible engagement models and superior infrastructure, SPEC INDIA is a customer’s delight. Our skilled technical resources are apt at putting thoughts in a perspective by offering value-added reads for all.