Continuous Success and why this should not be forgotten when developing a project (using the example of Drupal)
Your goal is a reliable and efficient product in Drupal (yes, however, on anything, but Drupal is closer to me in spirit, therefore I will concentrate on it)?
If so, then the long and thorny path of continuous integration (Continuous Integration), continuous inspection and continuous feedback is your way. As you might have guessed, the path is also continuous.
Guys, the last time I looked at the calendar, it was 2015 in the yard, the summer was hot, but the coffee was already cold. And in this era of technological innovation, accessible information, tons of materials on the Internet about how to do it, and even less about how to do it DO NOT NEED, people are still wildly felting their projects. And at the same time they drive companies into an immeasurable pit of technical debt.
')
Nevertheless, projects constantly fall into my hands in such a state that it is truly impossible to not believe in God or the devil, in this particular case. Such a number of defects is somewhere out there, “deep down”, simply unimaginable. Not that I was opposed, thanks to this campaign I am always provided with work and good material compensation. All this I am writing a) just out of interest: I really want to know your opinion, and b) you look, I will help someone. And I’m not worried about reducing the amount of work, I don’t think that in India (and from there comes the lion’s share of everything that needs to be fixed and redone) they read Habr. Sometimes it seems to me that the local coders do not read anything at all, but simply randomly drum on the keys until at least something somehow works. Well, okay, not talking about them.
Of course, I do not claim that continuous integration or its elements is the quintessence of perfect deployment, but the practice is good. Damn good.
According to SEI, cold fixes cost $ 2,656 for each line of code (I don’t give you a link to proof, it’s easy to google). And the lines of these are usually great variety, since the defects sit deep, look away and usually directly affect both the immediate functionality and technical / business requirements. It is the case when the defect is noticed and destroyed immediately after the appearance, when a few simple manipulations, manual dexterity and (sometimes) a small fraud are enough. This means less than the required code, significantly reduced costs of time and functionality that meets or even exceeds the requirements of both stability and further operation and maintenance.
As everyone knows, managers and programmers are different from each other. The latter, with their busy pens, write the code and know it by heart. So the manager may assume the stability of a product to launch based on the information received (correct or distorted), while the programmer determines that there are no defects in the code, thereby eliminating doubts about the readiness of a particular build.
TIP NO (continuous integration) eliminates doubts and gives access to a certain level of proactivity. Problems that may occur in any versions (git branches) are monitored on an ongoing basis, thereby adding the best QA elements to the development process.
Everything I write here will not make any sense without concrete examples. Yes, and we are not in the market for leg of lamb bargain, so that you believe my word about the freshness of this.
The main theses of continuous integration:
Continuous inspection is an important component of NI and its calling is as follows: this process must show and visually visualize the entire development process, so that it is clear to those great uncles at the helm who have the key to the apartment where the money is. That is, the inspection is an important and unshakable part, and it can be divided into the following elements:
1. Code analysis and report
2. Trends
3. Collected information telling about all the defects that have occurred in recent changes
4. Direct focus on core (for business) elements
5. Absolute control over all possible problems and defects.
Nokia - connecting people! This slogan is famous and applicable in a much larger number of cases than marketers of the manufacturer of unshakable hammers and fly swatters initially assumed. In our particular case, continuous feedback takes on the role of a Finnish work tool and builds bridges between all those involved in product creation.
Why is it needed? Well, of course, cultural communication is the basis of a healthy society, and a customer who is constantly in the know of everything is a satisfied customer (who does not go into the process with unnecessary, stupid questions). The main thing, as elsewhere, to do everything right! Follow the simple rule: “To the right people. At the right time. In the correct form. " How exactly to convey information is no longer a question for the century in which there is:
Well, now let's get to the point. Here is a small case for consideration.
The project: an online news portal that contains blog functionality, shows vidosiki (no, not that, what did you think, fi is up on you!) And represents the whole community. Technologies that feed our portal:
For the purpose of conspiracy and because of the bales of signed papers, all names have been changed, and the similarities with reality are purely accidental (well, or not entirely random, heh-heh). Let us return to our sheep. Here is the picture that initially appeared before my eyes are clear:
Do not worry, I know it is difficult, but try to overcome the desire to sprinkle the monitor with holy water, everything is ready.
So, the conclusion to which I came:
The architecture is clearly crooked, which led to the creation of a series of botnets, did not give the possibility of effective distribution within the system and became a huge headache in the content phase. In general, everything is not very repair and fit. The code does not meet the standards, and those debt amounts to as much as one and a half (one and a half) years!
What has been done:
What happened?
Judge for yourself, as for me - sweetie. Compared to what was at least. Anyway, the work is at 5 plus, because:
You yourself saw the result of a good job with the help of NO. Why is the methodology still so poorly distributed among those who develop a lot of external projects? This simply destroys outsourcing as an industry and undermines the credibility of normal specialists. And yes, I know that you can eat with both a spoon and a fork, and there are also other solutions. But why reinvent the wheel? Now tell me, do you use ANI, if so, how, if not, why?
If so, then the long and thorny path of continuous integration (Continuous Integration), continuous inspection and continuous feedback is your way. As you might have guessed, the path is also continuous.
Why am I doing this? (Disclaimer)
Guys, the last time I looked at the calendar, it was 2015 in the yard, the summer was hot, but the coffee was already cold. And in this era of technological innovation, accessible information, tons of materials on the Internet about how to do it, and even less about how to do it DO NOT NEED, people are still wildly felting their projects. And at the same time they drive companies into an immeasurable pit of technical debt.
')
Nevertheless, projects constantly fall into my hands in such a state that it is truly impossible to not believe in God or the devil, in this particular case. Such a number of defects is somewhere out there, “deep down”, simply unimaginable. Not that I was opposed, thanks to this campaign I am always provided with work and good material compensation. All this I am writing a) just out of interest: I really want to know your opinion, and b) you look, I will help someone. And I’m not worried about reducing the amount of work, I don’t think that in India (and from there comes the lion’s share of everything that needs to be fixed and redone) they read Habr. Sometimes it seems to me that the local coders do not read anything at all, but simply randomly drum on the keys until at least something somehow works. Well, okay, not talking about them.
Of course, I do not claim that continuous integration or its elements is the quintessence of perfect deployment, but the practice is good. Damn good.
Simple math
According to SEI, cold fixes cost $ 2,656 for each line of code (I don’t give you a link to proof, it’s easy to google). And the lines of these are usually great variety, since the defects sit deep, look away and usually directly affect both the immediate functionality and technical / business requirements. It is the case when the defect is noticed and destroyed immediately after the appearance, when a few simple manipulations, manual dexterity and (sometimes) a small fraud are enough. This means less than the required code, significantly reduced costs of time and functionality that meets or even exceeds the requirements of both stability and further operation and maintenance.
So why exactly continuous (integration + inspection + feedback) = continuous success?
As everyone knows, managers and programmers are different from each other. The latter, with their busy pens, write the code and know it by heart. So the manager may assume the stability of a product to launch based on the information received (correct or distorted), while the programmer determines that there are no defects in the code, thereby eliminating doubts about the readiness of a particular build.
TIP NO (continuous integration) eliminates doubts and gives access to a certain level of proactivity. Problems that may occur in any versions (git branches) are monitored on an ongoing basis, thereby adding the best QA elements to the development process.
How to integrate continuously?
Everything I write here will not make any sense without concrete examples. Yes, and we are not in the market for leg of lamb bargain, so that you believe my word about the freshness of this.
The main theses of continuous integration:
- Often (at least once a day) the code is entered into the storage
- Automated tests are written.
- Private builds are run (the process consists of a source code build that is stored in the developer repository, Developer repository)
- "Broken" code is not entered into the repository
- "Broken" builds are repaired
- All checks and tests are certified, as well as the fact that the code from the broken code storage is not used.
Continuous inspection
Continuous inspection is an important component of NI and its calling is as follows: this process must show and visually visualize the entire development process, so that it is clear to those great uncles at the helm who have the key to the apartment where the money is. That is, the inspection is an important and unshakable part, and it can be divided into the following elements:
1. Code analysis and report
2. Trends
3. Collected information telling about all the defects that have occurred in recent changes
4. Direct focus on core (for business) elements
5. Absolute control over all possible problems and defects.
Continuous feedback
Nokia - connecting people! This slogan is famous and applicable in a much larger number of cases than marketers of the manufacturer of unshakable hammers and fly swatters initially assumed. In our particular case, continuous feedback takes on the role of a Finnish work tool and builds bridges between all those involved in product creation.
Why is it needed? Well, of course, cultural communication is the basis of a healthy society, and a customer who is constantly in the know of everything is a satisfied customer (who does not go into the process with unnecessary, stupid questions). The main thing, as elsewhere, to do everything right! Follow the simple rule: “To the right people. At the right time. In the correct form. " How exactly to convey information is no longer a question for the century in which there is:
- SMS
- Special browser plugins
- Yes, even sirens or others, especially for this case, sound sound notifications
Well, now let's get to the point. Here is a small case for consideration.
Case example
The project: an online news portal that contains blog functionality, shows vidosiki (no, not that, what did you think, fi is up on you!) And represents the whole community. Technologies that feed our portal:
- Drupal
- MySQL (cluster)
- MongoDB
- Javascript
For the purpose of conspiracy and because of the bales of signed papers, all names have been changed, and the similarities with reality are purely accidental (well, or not entirely random, heh-heh). Let us return to our sheep. Here is the picture that initially appeared before my eyes are clear:
Do not worry, I know it is difficult, but try to overcome the desire to sprinkle the monitor with holy water, everything is ready.
So, the conclusion to which I came:
The architecture is clearly crooked, which led to the creation of a series of botnets, did not give the possibility of effective distribution within the system and became a huge headache in the content phase. In general, everything is not very repair and fit. The code does not meet the standards, and those debt amounts to as much as one and a half (one and a half) years!
What has been done:
- Restructuring architecture
- Code restructuring
- Hosting Platform
- Powerful (very) external caching
What happened?
Judge for yourself, as for me - sweetie. Compared to what was at least. Anyway, the work is at 5 plus, because:
- Database with 10 000 000 records
- 10,000 messages per second
- The site has repeatedly shone in the main page issuing on Yahoo
- 10 + K users per hour
Conclusion
You yourself saw the result of a good job with the help of NO. Why is the methodology still so poorly distributed among those who develop a lot of external projects? This simply destroys outsourcing as an industry and undermines the credibility of normal specialists. And yes, I know that you can eat with both a spoon and a fork, and there are also other solutions. But why reinvent the wheel? Now tell me, do you use ANI, if so, how, if not, why?
Source: https://habr.com/ru/post/263513/
All Articles