Shulou(Shulou.com)06/03 Report--

In this issue, Xiaobian will bring you the key models to consider in accelerating the pace of DevOps. The article is rich in content and analyzed and described from a professional perspective. After reading this article, I hope you can gain something.

Enterprise software development is a complex job, and only companies that can respond to market changes by delivering high-quality software quickly can dominate in the digital age.

There is no magic bullet for achieving the required level of business agility. It requires a shift from traditional waterfall thinking and old ways of thinking to lean agile thinking with associated principles and practices.

Scaling frameworks and DevOps methodologies can provide the guidance you need to transform your IT organization and the rest of your business. Agile at Scale Framework (SAFe) is the most popular methodology for scaling, articulating seven core competencies needed to succeed in the digital age: organizational agility, lean portfolio management, enterprise solution delivery, agile product delivery, team and technology agility, continuous learning culture, and lean agile leadership. However, success is still not guaranteed, as it will require careful implementation, preferably with the help of SAFe project consultants.

Leadership engagement, consistency, and systems thinking are my favorite ingredients for successful transformation. In addition to the common success factors described above, the framework is evolving. Practitioners continuously feed back field learning and experience into the framework. Here are two useful models and suggestions on how to use them in conjunction with the Software Factory approach to improve your DevOps implementation and enhance business agility.

As Peter Senge describes in his Fifth Discipline, teams and organizations need a shared mental model to generate consensus on problems and collaborate to find a good solution. To do this, I created what I call DevOps evolutionary models. The model was developed in my training sessions to explain how people can best progress on their DevOps journey.

This model can help you understand how to shorten lead times and shorten the length of feedback cycles by moving unfinished work to the left. (Outstanding work is the additional work required to publish the solution after the team has "finished" features and stories.) Typical examples of unfinished work are any type of testing, security checks and audits, documentation, open source legal assessments and compliance checks.)

Moving unfinished work to the left enables your team to provide faster feedback, resulting in more available products and faster bug fixes. This, in turn, speeds up the process and improves quality. Reducing or eliminating unfinished work results in more frequent releases and improved responsiveness to requirements changes.

Figure 1: The DevOps Evolution Model covers the four main stages of the DevOps journey and visually shows how your organization evolves from an immature model to a more mature model.

CI/CD pipeline model Continuous Integration/Continuous Delivery model evolved from SAFe DevOps training and follow-up workshops I conducted. Model end-to-end piping at the process level. CI/CD Pipeline Modeling delves into the details of the CI/CD pipeline and the associated build and integration processes. In my experience, many process problems in complex enterprise settings are a direct result of immature CI/CD pipelines.

To create a model, you need to bring all stakeholders together to draw the entire pipeline process (build, integrate, deploy, etc.) as nodes and edges. Nodes represent components, and edges represent relationships between components. While you might think your team already knows their end-to-end pipeline and will find this whole job useless, in my experience, it never does.

CI/CD pipe models allow you to see the whole picture. In large solutions, no one understands the end-to-end CI/CD process. By assembling the right people, you can see suboptimal results for local optimization and focus on efficient end-to-end improvements.

For example, teams often claim that they build and deploy several times a day, when in fact they are building and deploying the same code or component over and over again.

The key issue for CI/CD improvement is not the number of pipeline runs, but the time it takes the team to get from writing code to reaching the stage or production. This is the most important question you should ask for each contributing element.

CI/CD modeling improves quality due to reduced lead times. Defective components can have a domino effect on the integrated end product because development of components that depend on defective components is delayed. Even worse, if your team finds a defect late in the development process, you can't meet the plan that's already in place, or you may need to create shortcuts or workarounds to keep the plan in place. This reduces quality and increases technical debt.

Figure 2: This is an example of CI/CD pipeline modeling for a large enterprise product with over 100 million lines of code (click to enlarge). Each orange sticky label represents a large component (node), while the blue arrows are edges describing the build, integration, and deployment steps. Pink sticky notes show cycle time, lead time and complete and accurate percentage (%C&A). Green Sticky is the end product of phased deployment. Note that " LST" stands for "Large Solution Series" and " ART" stands for "Agile Release Series."

Enterprise advantages of the software factory approach Large enterprises are often seen as dinosaurs without DevOps. From the start, they lose market share, while smaller companies in emerging markets have agility and DevOps in their DNA. But while it is true that moving large businesses forward can be challenging, with SAFe you can transform successfully. You'll be able to create or change development value streams with minimal effort because people already have the same language and mindset, and they'll be able to quickly adjust strategies to respond to opportunities or threats.

Software factories complement this capability by enabling teams to adjust development settings faster to changing business needs and reduce upgrade and startup times. In addition, it helps reduce the cognitive burden on the team and improves efficiency, facilitating left shift and shortening delivery times.

The complex tool chains typically required to build enterprise software often result in cognitive burdens on the teams that use them. Consider pipeline improvements and maintenance activities required, such as keeping up with the latest tools and technologies, as well as upgrading build servers, operating systems, plug-ins, test automation tools, etc. This increases the pressure to recognize load release deadlines and the need to align with product and domain expertise as well as new features and bug fixes, and it's no surprise that many CI/CD pipelines are unstable and unreliable.

Pipeline as a Service can solve these problems and improve productivity. Dedicated experts maintain and continuously improve the services available to multiple product teams, thereby relieving the development team of the burden and allowing them to focus on their core responsibility of developing high-quality products in a short time.

To respond more quickly to changes in your development organization, you need to standardize your development tools. This allows for better tool integration and makes it easier for development teams to develop other products because they will be familiar with all the tools and core processes that other product groups are using. A standardized set of tools lays the foundation for modern software development methods such as shared code ownership and internal open source.

Standardizing tools using the Software Factory approach can greatly reduce licensing and maintenance costs, while also reducing the number of integrations and synchronizations required between tools.

If you have a lot of tools, there may be a lot of unreliable, semi-functional integration and expensive maintenance. This means unnecessarily high total cost of ownership, busy staff, and unreliable development data streams.

But standardization requires a careful balance. My advice is to standardize as much as possible while providing as much freedom as possible. Not all tools and processes are standardized candidates. Software factories usually start small and evolve based on adoption and user feedback. Figure 3 shows a validated Software Factory architecture with core elements.

Figure 3: This is Micro Focus's Software Factory architecture/blueprint showing the major components and categories of a fully functional software factory (click to enlarge).

How to get started mastering enterprise software and network physical systems is a complex task, and there are no simple solutions or magic bullets. Scaled Agile Framework and other frameworks can provide guidance and a solid foundation for your digital transformation journey.

Advanced DevOps models combined with the Software Factory approach can enhance and complement these offerings so your organization can thrive in the digital age.

The above is what the key models to consider to accelerate the pace of DevOps shared by Xiaobian are. If there are similar doubts, please refer to the above analysis for understanding. If you want to know more about it, please pay attention to the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.