This is a creation in Article, where the information may have evolved or changed.
"Editor's words" virtualization, containerized, cloud computing, Automation provides the underlying technical support for DevOps campaigns, and the adoption of new toolchain and technology stacks further reduces the technical barriers to devops, and more and more businesses are starting their own DevOps transformation path, however ...
This share we will discuss:
- The current state of DevOps and Enterprise DevOps transformation
- Why we need to emphasize metrics in a devops transformation
- How to achieve a measure-driven devops transformation
- Other practices in the DevOps transformation
On the wiki: DevOps (development and operations) is a culture, movement, or convention that attaches importance to the communication between software Developer (DEV) and IT Operations Technician (OPS) (this is the goal) through automated "software delivery" and " Schema change "process (this is the method) to make building, testing, and publishing software faster, more frequent, and more reliable (this is the result).
Therefore, the real value for the enterprise is that through the improvement of the collaborative relationship between the team, the whole organization efficiency can be improved, and the risk of the production environment which accompanies the frequent change will be reduced effectively, so as to improve the enterprise response to the market change.
According to the DevOps survey report. The successful implementation of DEVOPS organizations can quickly adapt to changes in the entire market environment while making adjustments faster.
have higher deployment frequency compared to competitors, faster recovery times, lower change failure rates, and a shorter demand delivery cycle.
And then, as companies embrace and use these new toolchain, we don't see that the software we deliver is really like a devops goal, delivering software quickly, frequently, and reliably.
DevOps is not a blind use of new toolchain and technology stacks, and the deployment of low-quality code frequently to the running environment by automating the deployment pipeline.
The traditional enterprise that is currently implementing the DevOps transformation, by introducing automation, can certainly improve the efficiency in some parts of software delivery, but it is difficult to improve the quality of software delivery, still introduce the independent testing department to carry out a lot of system testing to ensure the quality of software, It is also difficult for companies to measure the effectiveness of continuous delivery and DevOps implementations.
So for now, most companies are basically automating as devops, automating deployment as ongoing delivery, and rarely considering the overall optimization of the software delivery process.
Automation is a prerequisite for implementing devops but it does not really help companies to cross the gap between DevOps transformation and silver bullet.
For the successful transformation of devops, what we need to do is continue to optimize our software delivery process, identify bottlenecks in every aspect of the software delivery process, and continually improve.
You can ' t Fixed the What can ' t.
Data and metrics are the key foundation for helping companies discover bottlenecks in the DevOps transformation process and to make improvements.
At the beginning we said that from a wiki, DevOps would be designed to be primarily 3 parts: goals, methods, and results.
So from the delivery of metrics we need to measure our devops transformation from two aspects. Which metrics are able to support the enterprise to determine the results of a devops transformation. And which are able to judge the delivery process of the software and to find the delivery bottleneck.
According to the 2016DevOps report, the final outcome key metrics that currently measure the success of Enterprise DevOps transformation include:
Throughput metrics: Deployment frequency, change delivery cycle.
Stability Indicator: Change failure rate, problem average recovery duration (mean time to recover).
Throughput is agility, ensuring that businesses are able to adapt to changes in the market and quickly make feedback. stability, i.e. high quality.
Compared to traditional IT service process performance indicators ITIL, DevOps pays more attention to the results of the indicators, namely customer value.
Just like we do software delivery and take-out small brother actually very similar, can evaluate a product is good more is to see the delivery efficiency, how quality, and is not able to meet my expectations?
These two radically different measures are essentially the difference between OKR and KPIs:
OKR is based on goals and key outcomes that motivate us to think, communicate, and everyone knows what is most important, and enables the team to work together for something.
So for OKR-driven devops, it is possible to ensure that the roles involved in the software delivery process are around the goals that are passed, and to try out new technologies and methodologies for these common goals.
While KPI theory avoids being made according to smart standards, some things are worth doing, but cannot be measured before they are done. The KPI has a more serious problem, that is, in order to achieve measurable goals, it is possible that the actual means of execution is the opposite of the vision that the goal is to achieve.
KPIs allow the team to move forward, while OKR ensures that the team can move in the right direction. In the software delivery process, development, testing, operation and maintenance have different assessment standards. So the KPI is able to push each member of the team to follow their own goals, while OKR ensures that the team can go in the right direction together.
DevOps needs a holistic optimization, and when you choose your own internal metrics, ask yourself two questions:
Why do I need to measure this indicator? What can we learn from this indicator?
According to the DevOps 2016 report, there is a significant difference between an efficient IT organization and a moderate and inefficient it organization in terms of the eventual outcome of a DevOps key metric.
The ultimate results of devops can help companies measure and judge the results of a devops transformation.
Of course, in addition to the results of the indicators to verify the role of the DevOps transformation, we also need to continuously measure other data to help us discover the issues at various stages of software delivery.
Including requirements management, source management, build process, test process, deployment process, release, configuration management, monitoring and other aspects, here we list the various processes may need some of the measurement data.
Among the more typical include the measurement of demand management, we can know the change delivery time from demand to demand deployment.
In the CI process we continue to obtain relevant process data, such as number of builds, build frequency, build time, success rate, average recovery time, etc. can help the team to determine whether the development team can do small steps to submit, frequent submissions, and when the problem can be quickly recovered.
In addition, low-quality, high-complexity code can also make software delivery efficiency can not be effectively improved, so we need to continuously obtain code quality-related data, continuous improvement of code quality and so on.
So for a metric-driven devops transformation, we need to continue to capture the data generated at all stages of software delivery, as well as monitoring data, user behavior data, and so on, after the software deployment goes live, and to form a devops visual kanban that is visible to the team owner.
Product/Demand managers can evaluate the effectiveness of DEVOPS implementations over a period of time based on devops results, identify bottlenecks in the delivery process from the process data, and evaluate the SOFTWARE product as expected, based on data and online monitoring data. If not, should make a timely adjustment.
In addition to automating the process of building software delivery end-to-end processes to improve software delivery, and continuously capture data generated at various stages of software delivery.
We should also be in the software delivery process to set up the appropriate access control mechanism, so that the failure to meet the quality requirements of the building quickly failed.
In practice, the process of running end-to-end automation depending on the volume of the SOFTWARE PRODUCT may be very long.
Therefore, for the research and development team, the continuous deployment process produces a long feedback cycle, not conducive to the development team to quickly identify and solve problems.
Basic CI pipelining is executed frequently, triggered by code submission, including build, unit test, integration test, code static scan, partial automated acceptance test, etc. (end-to-end running cycle is short).
For TEAM: Full-line daily scheduled multiple triggers, including build, unit testing, integration testing, code scanning, full-scale automated acceptance testing, deployment, deployment of smoke tests, etc. (end-to-end operation cycle length).
For QA: Manually specify a version deployment and trigger manually.
Through the layered pipeline, while satisfying the principle of fast feedback, it can continuously integrate and test the software.
At the same time in the pipeline through the introduction of quality door to control code quality, avoid the accumulation of technical debt.
Of course, for legacy systems, there is usually a lot of historical debt, when we can use the code quality of the current system as a baseline and set the quality Gate control for new code, including code style, complexity, test coverage, and so on.
Through the visual pipeline will be the continuous deployment pipeline construction process to show the entire team, so that everyone knows the current project build status and progress, if the build failed, the members can also remind each other as soon as possible to repair the failure of the pipeline.
Continuous access to process validation data and quality effectiveness data provides a visual Kanban board for the team.
In addition to access control mechanisms, quality built-in is also a key factor in the team's successful implementation of DevOps, enabling the team to identify and resolve discovered defects as early as possible by establishing automated assurance systems at all stages of software delivery.
Measure-driven DevOps transformation, effectively improve software delivery efficiency through automated deployment lines, ensure the quality of software delivery through quality built-in, and uncover bottlenecks in the delivery process through continuous collection and analysis of process data to gain feedback and timely adjustments to software products and users ' online data To evaluate the effectiveness of the team through results-based data.
Finally, for Enterprise DevOps transformation:
Automation Automation is a prerequisite for implementing a devops transformation, automating everything that can be automated to reduce the difficulty of deployment and release.
Measure supports business decisions by building effective monitoring and measurement tools to get feedback, driving continuous improvement of products and teams.
Lean Collaborative culture, automation, and effective feedback, these implementations are a long-term process that needs to be run in a lean way to continuously improve processes and technologies.
The culture OKR goals and key outcomes drive the creation of an integrated team with a cross-functional cultural and common goal; This is the foundation of DevOps!
Sharing to share ideas, knowledge, problems, and failure experiences in the development and operations process between different functions and products, and to jointly enhance their capabilities.
Q&a
Q: How does a CI/CD based on Jenkins manage different users? How are permissions controlled?
A: Advocating a fully empowered team within the DevOps implementation, so that the team has its own exclusive Jenkins master on the basis of infrastructure self-service to effectively reduce permissions to control such issues, while avoiding the interplay of build tasks across teams If it is a shared jenkinsmaster,jenkins, a plug-in with rights control can control the user's permissions.
Q: Just now you introduced the CI entire delivery process, each detail need to spend a lot of time and effort to develop and implement, if the company team a lot, if the time to allocate their own team, time is less natural to reach the effect.
A: In the implementation of the DevOps transformation process, you can first try the pilot team, through the pilot team to complete the DevOps tool chain-related technology selection, in the case of mature tool chain to other teams to promote.
Q: Do you have a devops platform for automated operations? It could be a Web page that integrates DevOps-related processes and tools, facilitates management, and facilitates operational development integration. This platform may also include a full-link detection system?
A: At present, our company is based on the container continuous delivery platform is mainly to solve such problems, through the pipeline to organize the tool chain, at the same time to measure the relevant links, in order to avoid the suspicion of advertising is more inconvenient to say.
Q: How do you manage communication in this process to prevent problems caused by the deviation of the understanding of the requirements?
A: This is more of a team's organizational structure, and it is interesting to try the Kanban method, the team's roles will be based on Kanban to complete the development of the iteration, through the Kanban can help the communication between team members and demand confirmation.
Q: Because it is very simple, continuous integration continuous delivery, rapid iteration, fast pace, slow, and so on, all of these theories return to the code, all the changes return to the source code changes, how to ensure that all the changes are not omitted, how to ensure that each task is on the correct code baseline, How did the problem quickly feed back to the forefront of research and development to stop the problem from spreading in time?
A: This is actually the main way is based on the continuous deployment of the pipeline, the above share of the time mentioned. Through the pipeline through the automated pipeline control, at any stage of the problem should let the pipeline failure (access control), the other problem is not afraid, the problem is the key to fast, for the pipeline best can be set webhook real-time trigger, you can ensure that when the problem occurs, The domain of the problem code can be associated to the most recent commit.
Q: How does your container release automatically differentiate between development, testing, formal and other environments, and does it require manual intervention to modify application access relationships and launch environment variables?
A: At present, our own continuous delivery platform docking different container operating environment (currently mainly rancher), the team will be classified management of the environment, the pipeline in the deployment of containers when the appropriate environment can be selected; In addition, because it is mainly based on the container, it also divides the different states of the container image. It also flows between multiple registry instances, physically isolating the container image for development, testing, and release status. The part of manual intervention is mainly to control the change of the mirror state.
Q:jenkins Pipeline and ordinary project can support the pipeline, 2 people have a difference?
A: The main problem is how to quickly locate the problem when building the problem, if there are 8 stages in the pipeline line, if it is only implemented in a project, developers need to spend a lot of time positioning; if it is build pipeline, It is very intuitive to know what stage the problem is occurring.
The above content is organized according to the January 17, 2017 night group sharing content. Share people
Zheng Yunlong, a leader in continuous delivery of products to agile and DevOps, has extensive hands-on experience as an agile and DevOps technology instructor to provide consulting and training services to a large number of companies in the past .。 Dockone Weekly will organize the technology to share, welcome interested students add: Liyingjiesz, into group participation, you want to listen to the topic or want to share the topic can give us a message.
