I remember when I was just in college, the popular major was called software engineering. This major used foreign tutorials, and the tuition fee was much more expensive than the average major, which was about 1.5 times more expensive. Therefore, it has always been very complicated to engage in software and even feel high-end. one thing.
I read "The Mythical Man-Month" later, and to be honest, I remembered a sentence, there is no silver bullet in software development, which once again proves that software is not easy to do. (The digression is that this book is actually a bit high for students who are studying in university or just engaged in development, and it is too abstract. Only after personally participating in some relatively large projects will you understand more and more.)
Over the years, I have experienced CMM model, agile development, devops, participated in projects developed by thousands of people, and also worked on small projects with a few people. I have also done various roles, such as development, project management, product, The person in charge of the business, etc., have some more experience, and here is how to do the most popular devops.
Of course, I am not professional in engineering efficiency, and this article is not a tutorial to discuss how to do software engineering or how to do devops. The core is to discuss the value of devops, some key pre-factors, and some logic behind it.
Let's take a look at the direct value brought by devops implementation:
Value to Customers: Faster Response
By releasing by feature, feature releases can reach days
Faster response to customer needs
Value to Product: Improving Quality
Reduce the scope of release each time, reduce the probability of errors, and improve quality
If there is a problem, you can respond in time; through rollback or quick repair, improve product quality
Value to the team: Activate the organization, simplify management, and improve performance
Through reasonable dismantling, the degree of coupling is reduced, and the enthusiasm of the team is improved by dividing the fields into households; reducing eating in big canteens, waiting for each other, and reducing performance caused by context switching. For team members, they can grow quickly and take responsibility, which is also very helpful.
For managers, it can release inefficient organizational collaboration and focus on higher-level business opportunities and project opportunities.
Open up the boundary between development and operation and maintenance, and reduce context switching. In addition, through reasonable microservice splitting, the difficulty of a single task becomes lower
To implement a software change is actually not a simple requirement, but a system engineering. There are some key pre-requisites in devops:
Microservice architecture split
CI/CD tools
grayscale environment
Team culture transformation: the recognition of ideas, the recognition of changes in working methods, and the continuous cultivation of T-shaped talents
When many teams are facing the problem of development mode transformation, my suggestion is
Early implementation is better than late implementation: early implementation has less burden on customers and business
Doing it right away is better than planning in detail:
The difference in individual development efficiency will be relatively large, so bandwidth estimation is very difficult, so compared to activating organizational potential, the value of detailed bandwidth estimation is much smaller;
Planning is necessary, but business changes rapidly, and an agile organization is more valuable, so it is more valuable to do it immediately than to plan everything in detail
Macroscopic overall planning is needed, otherwise there will be a lack of sense of direction
Consider starting with one/multiple modules, gradually practicing and gaining experience, and the most important thing is the transformation of teammate culture, everyone understands and accepts the new model.
I have talked about a lot of wild ways of practice before, returning to the academics of Devops and defining the essence. There is a theme of "CALMS":
Culture - refers to embracing change, fostering collaboration and communication
Automation - refers to the removal of human intervention from the value chain
Lean - Refers to the use of Lean principles to drive high frequency cycle cycles
Metrics (indicators) - refers to the measurement of each link, and through the data to improve the cycle
Sharing - refers to openly sharing successes and failures with others and learning from mistakes
You will find that what you said above can be mapped to CALMS, and the understanding will actually be deeper if you compare it.
In addition to the various values mentioned above, I think the greater value of devops lies in the stimulation of human nature. The biggest difference from traditional Agile and CMM models lies in the difference in management logic. If this difference is explained by the classic lock in the database, it is actually the difference between optimistic locking and pessimistic locking. In addition to various tools and routines, the core of devops is to be able to activate the active owner awareness of individual team members. Let them dare to fight and do it.
So devops will be the end? I don't think so. Software engineering management will continue to evolve and develop to release greater productivity.