2017 State of DevOps Survey Report (Official Chinese Version)
http://www.idcos.com/download/devops-report
Reading summary:
DevOps practices are now deeply ingrained into a corporate culture. Help enterprises improve application deployment efficiency, ensure system quality and security, and quickly adapt to the market.
DevOps helps improve IT effectiveness, helping businesses increase productivity, increase profits, and expand market share.
How can effective leadership influence the improvement of technology practices and processes to improve IT and organizational effectiveness?
Automation is the core competitiveness of an enterprise.
Overview:
1. Good constructive communication skills, good encouragement and inspiration, and personal charisma, these leadership traits are closely related to IT effectiveness. The leaders of high-performing teams have all of these characteristics. In contrast, the leaders of low-performing teams lack these competencies.
2. The gap in the release frequency, release delay and other indicators of different performance teams is narrowing. But failure recovery times and release failure rates for low-performing teams have risen. The reason for this is that as the frequency of releases increases, quality control over builds loosens.
3. High-performance teams are significantly better than other teams in the automation of configuration management, testing, release, and approval processes; thus, high-performance teams have more time to innovate and respond quickly to the market.
4. In order to achieve high IT performance, please adopt a loosely coupled service architecture, that is, services can be independently developed and deployed; and a loosely coupled team, ready to make changes at any time. Achieving the above changes requires huge investment from traditional enterprises. The benefits of a loosely coupled architecture are: Higher performance, quality and stability.
5. Lean product management practices help teams deliver products that meet market needs and have shorter lead times. Fast delivery brings the R&D team closer to the customer. The result is an increase in profitability, productivity and market share across the organization.
leadership:
Leadership has a major impact on business. Good managers lead teams to release high-quality code, build high-quality systems, and apply lean principles in product development. These capabilities have a direct impact on a firm's profitability, productivity, and market share. For organizations and government agencies that are not measured by profit, leadership is related to customer satisfaction, organizational efficiency, and the achievement of organizational vision.
How leadership can help businesses improve efficiency is an easily overlooked area of DevOps practice. Leadership is essential in tasks such as:
- Create and encourage a cultural atmosphere of mutual trust
- Improve production efficiency through technical means, reduce deployment delays, and improve reliability
- Support team innovation, release products faster and better
- Break down departmental boundaries and agree with organizational vision
There is often a lack of buy-in to management within the DevOps community, for example, middle managers sometimes hinder changes to improve IT and organizational efficiency. A frequently asked question is how can we get management to support us in making changes and improvements? All agree that management buy-in is necessary for a successful DevOps practice. The budgets and processes required for large-scale changes must be approved by management. If obstacles are encountered in the change, the team needs the support and encouragement of management. Management is responsible for setting the tone and culture of the organization.
The five quadrants of leadership:
But good leadership doesn't equate to DevOps success. Among the top 10 percent of organizations for leadership, DevOps results are mixed. Because the success of DevOps depends not only on leadership, but also includes a reasonable organizational structure, good technical practices, adherence to lean management principles, and many other factors.
The pains of implementing automation for mid-level teams:
The increase in redo and manual work in the automating process of mid-level teams is only a temporary phenomenon. By implementing automation, teams are experiencing real results while experiencing significant technical debt that hinders the advancement of DevOps and automation. We recommend that the team not pursue excessive control over the automation process, but gradually shift from the form of approval committees to technical means such as code review and test automation that are common in the R&D cycle. Eventually the organizational form of the Change Approval Committee will disappear and be replaced by a faster and more reliable approval process. Once the technical debt is resolved, the team can move forward with automation and DevOps practices.
DevOps technical practice:
DevOps helps deploy software faster, improve team efficiency, and maintain an organization's competitive advantage. Organizations looking to implement DevOps often start by purchasing the appropriate DevOps software, but more importantly follow DevOps-related technical practices. Our questionnaire report examines these technical practices in depth, including version control, continuous integration, trunk-based development patterns, and automation . This year's questionnaire adds practical content on system architecture and organizational structure, including their impact on software development and deployment efficiency.
Continuous Delivery:
The technical practices for successfully implementing continuous delivery include: complete code control, continuous integration, trunk-based development, introduction of security compliance in R&D, implementation of testing and deployment automation. Of course, test automation is the most critical .
The key to success in continuous delivery (more important than automated testing and deployment) is whether the team does the following:
- Implementing large-scale changes does not require approval from someone outside the team
- Implement large-scale changes that do not depend on changes to systems owned by other teams and do not add additional workload to other teams
- No need for detailed communication with other teams
- Changes as needed, do not depend on the updates of other services, and do not affect systems that rely on this service
- Most tests can be done without an integrated test environment
- Deploy at business hours without compromising business continuity
Trunk based development:
The report examines the impact of a trunk-based development model on continuous delivery. Research has shown that high-performing teams choose to work on small code branches and merge into the master branch in a timely manner, rather than keeping numerous feature branches. The following practices can help improve software delivery efficiency:
- Merge code to master branch (Trunk or Master) daily
- Shorten the lifetime of branches and forks (less than one day)
- Only maintain less than three active branches
Teams that don't introduce code lock-in periods are more productive in releases (the practices listed above help avoid code lock-ups).
Although trunk-based development improves software deployment efficiency, some developers who are used to adopting the "Github recommended development process" are skeptical. The "Github Recommended Development Process" recommends developing based on branches, only periodically merging into trunk. Working on short branches and merging into trunk daily is one of the best practices for continuous release. Branch-based development is also efficient if the branch lifespan is short enough. The question is how long exactly does "short" refer to?
In this year's questionnaire, we specifically analyzed the difference in efficiency between adopting a trunk development strategy and a branch development strategy. Points of consideration include the survival time of a branch or fork before being merged into master, the time overhead of branch merging, and the differences in branching strategies of different performance organizations. The following are our findings:
- High-performance teams have short merge times and branch survival times, both in hours
- Inefficient teams have long merge times and branch survival times of days
The questionnaire revealed that high-performing teams had shorter branch survival times and shorter branch merge times. Questionnaires over the years have revealed the same best practice: avoid branches that live longer than a day. If the branch merge and integration take more than a day, this is a warning message, reminding the team to re-examine the system architecture and branch strategy.
Collect customer feedback:
One of the goals of agile methods is to incorporate customer requirements throughout the development cycle, even when the product is still in the early design stages. This allows the R&D team to capture important customer feedback and apply it to the design. If the R&D team is not allowed to update specifications or requirements based on collected customer feedback, or if such changes require external approval, the team's ability to innovate can be greatly reduced.
The distinction between tool projects and strategic projects:
Understand the difference between tool projects and strategic projects and treat them differently. The distinguishing principle put forward by Martin Fowler is whether its function is the core competitiveness of the organization. If the answer is no, consider purchasing commercial software on the market rather than developing it yourself. A common mistake is to mistake tool requirements for strategic requirements, and develop or customize them with great effort, instead of actively adjusting their business processes to adapt to mature commercial systems.
Mistaking tool requirements as strategic requirements can lead to serious consequences, including spending a lot of effort customizing a black-box system that is difficult to maintain, test, and upgrade, which cannot be incorporated into the service life cycle of automatic testing, automatic release, and maintenance , and automation is at the heart of DevOps practices. Rather than making costly customizations to commercial systems, it is better to adjust your business processes to fit the system as part of business process optimization. In many cases, this is a lot less expensive than customization. In any case, it is beneficial to periodically revisit corporate processes.
The above practices may go against the tradition of R&D organizations that do not readily accept third-party-developed software, and many engineers agree: we do it better. However, implementing this practice allows energy and intelligence to be focused on creating a competitive product that keeps the business invincible.