How does Devops appear? Antecedents and consequences
For more knowledge of Internet of things high concurrency programming, please move to https://www.yuque.com/shizhiy…
The evolution of software development
Over the years, Devops have evolved from existing software development strategies / methods to respond to business needs. Let’s take a brief look at theseHow the model evolved, as well as their most suitable scenarios.
- The slow and cumbersome waterfall model evolved into agile, and the development team completed the software development in a short time, which lasted no more than two weeks. Such a short release cycle helps the development team process customer feedback and incorporate it with bug fixes into the next release.
Although this agile scrum method brings agility to development, it loses the speed of agile practice in operation and maintenance. The lack of collaboration between developers and O & M engineers will still slow down the development process and release.
- The Devops method isBased on the need for better collaboration and faster delivery。 Devops allows continuous software delivery with fewer complex problems to fix and resolve problems faster.
In order to better understand what Devops is, it is necessary for us to review the history of the existence of the title of programmer (developer, foreground engineer, background engineer, etc.) at that time.
As the way of programming says:
The older generation of programmers are mysterious and profound. We can’t figure out what they think, all we can do is describe their appearance.
- Awake like a fox swimming across the water
- Alert like a general on the battlefield
- Friendly as a hostess
- It’s like a piece of uncut wood.
- Like a pool of dark water in a deep cave.
i am you father
Programmers have developed machine languages, machine languages have produced assembly languages, assembly languages have produced compilers, and now there are too many languages.
Each language has its own humble uses. Every language expresses the Yin and Yang of software. Every language has its place in this way.
Back then, most of the companies run by software programmers were called labs, and programmers were called scientists. In order to develop a good set of software, programmers must have a deep understanding of all the application related problems they need. They must know exactly where the software is applied and what system it must run on. In essence, programmers have a thorough understanding of all aspects of the software to be developed, from specification writing, to software development, to testing, to deployment, to technical support.
After a while, the characteristics of human (customer) greed began to show, and they began to ask for more. Faster speed, more features, more users, more everything.
As a humble, humble, and peaceful creature, it will be difficult for our older generation of programmers to survive this explosive and excessive demand demands. The best way to win is to evolve into new species in different directions.
Soon, the title of programmer began to disappear in the Jianghu, and more new species were born, such as developers, software engineers, network administrators, database developers, web developers, system architects, test engineers and so on. Rapid evolution and rapid adaptation to external challenges have become part of their DNA. These new races can evolve in a matter of weeks.
Web developers will soon evolve into background developers, foreground developers, PHP developers, ruby developers, angular developers… There’s a lot to look at.
Soon they all forgot that they all originated from the common ancestor of programmers, that there was such a simple and peaceful scientist who wanted to make the world a better place. Then they began to fight, claiming that they were the pure heirs of “programmers”.
With the shift of time, all sects began to monopolize the mountain and rarely communicate with each other, only when they had to. They began to stop cheering for the success of their distant cousins, or even sending a postcard to ask for help from time to time.
But when they look up at the starry sky at night, they will still find that the programmer gene in their heart will keep flickering, hoping that the flickering spark will light up the whole galaxy and bring peace.
Waterfall opening process
In this selfish and self-centered race to conquer the world, the descendants of programmers have long forgotten their real goal of working to solve problems for customers. In the face of delayed project delivery dates, expensive development costs, and even ultimately failed projects, customers began to hate this situation.
Occasionally, there will be a shining star standing up and offering a way to try to end the chaos and bring peace.So the waterfall development process came into being.。 This is a great idea because it takes advantage of the fact that developers from different teams communicate only when they have to. When a team finishes their work, it will communicate with the downstream team and pass down the tasks, so that they can pass on one by one and never look back
This approach worked for a while, but soon, as always, greedy people (customers) began to make more demands. They hope to be more involved in the whole software development process, and put forward their suggestions from time to time, and even put forward the insane thing of changing requirements late.
As a result, as you can see, the saying that software projects are very easy to fail has been accepted as an industry standard. Data show that more than 50% of projects end up in failure. What’s more, at that time, it seemed that people had nothing to do with this situation.
Fortunately, in every era, there will always be so many open-minded heroes like fireflies in the dark. They know that the developers of these different teams must find a way to work together, communicate with each other, and flexibly guarantee the best solution to customers. This kind of attempt can be traced back to 1957, the efforts of the great John von Neumann and his colleagues.But we didn’t reap the fruits of the revolution until 2001, when more than a dozen elites in the industry created the world-famous “Agile Manifesto”。
The Agile Manifesto is based on the following 12 principles:
- Our first task is to satisfy our customers by delivering evaluable software as early as possible and continuously.
- Be willing to accept requirements changes, even in the late stages of development. Agile process can control change, so as to win the competitive advantage for customers.
- Frequent delivery of available software, the shorter the delivery interval, the better, from weeks to months.
- Throughout the development of the project, business people and developers must work together day and night.
- Build projects around people who are motivated. Give them the environment and support they need, and trust them to get the job done.
- The fastest and most effective way to communicate with and within a development team is to talk face to face.
- Available software is the main measure of progress.
- Agile process advocates sustainable development. Investors, developers and users should always work together to maintain a stable development speed.
- In order to enhance agile capability, we should continue to pay attention to outstanding technical achievements and good design.
- Simplicity – the art of maximizing unnecessary effort – is essential.
- The best architectures, requirements, and designs come from self-organizing teams.
- Teams should periodically reflect on how they can become more effective, then change and adjust their behavior accordingly.
The Agile Manifesto is an important first step towards bringing peace to the galaxy and maintaining their own balance. For the first time in a long time, this is the way to connect different key project stakeholders based on culture and “human nature” compared with previous methods based on process and mechanization. People began to communicate with each other, held basic meeting, and began to exchange views and opinions constantly. They began to realize that they had more in common than they thought, and customers began to become one of them, instead of just throwing money at the project as before, and then began to pray to God and Buddha for everything to go smoothly.
Lean software development
Although there are still many obstacles to be overcome, the future is much brighter.Agility means openness and embracing change. However, if there are too many changes, it is difficult for people to focus on the ultimate goal and delivery. At this time, lean software development began to break the ground.。
Because of the fascination with lean software development and the purpose of banishing and driving away risks, some descendants of programmers began to look out of the window and learn from industries other than software. They found salvation in a major car manufacturer. The achievements of Toyota Production System in lean are inconceivable. At the same time, their lean production experience is easy to apply to software development.
Lean has the following seven principles:
- put an end to waste
- Built in quality
- Create knowledge (enlarge learning)
- Delay decision (delay decision as much as possible)
- Quick delivery
- Respect for people (team empowerment)
- global optimization
If we put this into agile, lean principle can make people focus on doing the right things in spirit, and at the same time make the whole development process flexible enough.
Once agile and lean software development are adopted by software development teams, the next step is to apply this set of principles to it teams. Put it into the overall strategy, and then we come to Devops!
Access to Devops – three lanes of motorway
The old software development team will include business analysts, system architects, front-end developers, back-end developers, testers, etc.
The focus of optimizing software development processes such as agile and lean principles lies in these areas.
For example, once the software reaches the “can be produced” level, it will be sent to the “operation and maintenance personnel” such as system engineer, release engineer, DBA, network engineer and security expert.
How to bridge the gap between dev (Development) and OPS (operation and maintenance) is the main focus of Devops.
Devops is the result of implementing lean principles across the IT value stream. The IT value stream extends development to production, bringing together all the descendants of programmers, a distant ancestor.
This is the best parsing of Devops from gene Kim.
You should not recruit Devops engineers again, and Devops should not be a new IT department.
Devops is a kind of culture, a kind of idea, and is integrated with it.There is no tool in the world to turn your it into a Devops organization, and there is no automated way to guide you in how to maximize the benefits for your customers.
Devops are generally known as the following three ways, and in my eyes I see them as three lanes on a highway. You start in the first lane, then accelerate into the second lane, and finally drive at high speed in the third lane.
- Lane 1 – overall efficiency considerations at the system level are the primary concern, which outweighs any individual element of the system
- Lane 2 – ensure that continuous feedback loops are provided and are not ignored.
- Lane 3 – continuous learning and learning, continuous progress, rapid failure.
Lane 1 – get speed
To adopt the principles of Devops, understand the importance of the whole operation system and prioritize the work items properly is the first thing an organization should learn.No one can be allowed to create bottlenecks and reduce the whole workflow in the whole value stream.
Ensuring that the workflow is uninterrupted is the ultimate goal of all members in the process. No matter what the role of a member or team is, they must try to have a deep understanding of the whole system. This way of thinking will have a direct impact on quality, because defects will never be relegated to the “downstream”, which will lead to bottlenecks.
It’s not enough to ensure that the entire workflow is not blocked by bottlenecks. A productive organization should always consider how to improve the whole workflow. There are many methodologies that can do this, and you might want to look at constraint theory, six sigma, lean, or Toyota production systems.
The Devops principle doesn’t care which team you are on, whether you are a system architect, DBA, QA, or network administrator. The same rules cover all members. Each member should follow two simple principles:
- Keep the operation process of the system uninterrupted
- Improve and optimize workflow at any time
Lane 2 – shift acceleration
Non interruptible system processes are directional and are expected to flow from development to O & M.In an ideal world, this means rapid development of high-quality software, deployment, and value to customers.
But Devops is not utopian. If one-way delivery is feasible, our waterfall model will be competent. Assessing deliverables and communication throughout the process is essential to ensure quality. The first upstream oriented communication channel that must be implemented here is from OPS to dev.
It’s very easy for us to masturbate on our own, but getting feedback from others and providing feedback to others are the right way to explore the truth. Every step (feedback) downstream must be followed by an upstream determination.
It doesn’t matter how you build a feedback loop. You can invite developers to a technical support team meeting, or put network administrators in a sprint planning meeting. Once your feedback mechanism is in place, and the feedback can be received and processed, you are on the Devops freeway.
Lane 3 – fast forward
Devops is not a fast lane for people with weak wills. In order to enter this lane, your organization must be mature enough. It is full of risks, learning from failure lessons, constant attempts, and the recognition that repeated failures and constant practice are the preconditions for success.
You should often hear the word “routine” here for a reason. Constant training and repetition can cultivate a master because it makes complex movements routine.
But before you can connect these complex actions, it is necessary for you to master each individual step.
“The movements suitable for the master are not suitable for the novice. You must understand the true meaning of Tao before you are reborn. “
The third way / fast lane of Devops includes allocating time every day for continuous testing, often rewarding teams who dare to take risks, and deliberately introducing defects into the operating system to increase the system’s combat ability.
In order to ensure that your organization can digest these methods, you must establish a frequent feedback loop between each team, and at the same time, you need to ensure that all bottlenecks can be cleared in a timely manner, and that the operation process of the whole system is uninterrupted.
Implementing these measures will keep your organization alert at all times and be able to deal with challenges quickly and efficiently.
Here is a list that you can use to test your organization’s application of Devops.
There are no barriers between the development team and the O & M team. Both are part of the Devops unified process.
The flow of work from one team to another can be verified with high quality.
- The work is not piling up, all the bottlenecks have been dealt with.
- The development team does not occupy the time of the operation and maintenance team, because the deployment and maintenance are in the same time box.
- The development team will not deliver the code for deployment after 5pm on Friday, and the rest of the operation and maintenance team will work overtime on weekends to wipe their ass.
- Development environment is standardized, which can be easily extended and deployed by operation and maintenance personnel
- The development team can find the right way to deliver the new version, and the operation and maintenance team can easily deploy it.
- The communication lines between each team are clear
- All team members have time to test and Practice for improving the system
- Conventional defects are introduced (or simulated) into the system and processed. The experience learned every time should be documented and shared with relevant personnel. Accident handling becomes a part of daily work, and the handling method is known.
Using modern Devops tools, such as chef, docker, ansible, packer, tropisphere, consul, Jenkins, sonarqube, AWS, etc., does not mean that you are applying the principles of Devops correctly.
Devops is a way of thinking。 All of us are part of the system process, and together we share common time and delivery value. Everyone involved in the software delivery process can speed up or slow down the operation of the whole system. A defect in the system and the “firewall” between misconfigured teams may cause the whole system to fail.
All of us are part of Devops. Once your organization understands this, tools and technology stacks that can help you manage them will naturally appear in front of you.