Read the word count: 2237 | 4 minutes to read
suo.im/4O9wKu
Abstract
As DevOps moves across the enterprise, the most important part of the DevOps tool chain will be built — whether it’s based on open source solutions or homegrown systems. In the process, how to build an easy-to-use DevOps tool chain that truly achieves DevOps goals:
1. Look at what the DevOps tool chain is trying to accomplish from a continuous delivery perspective.
2. Define the scope and meaning of DevOps toolchain ease-of-use.
3. Explore how to achieve ease of use by combining the goals of the DevOps tool chain with cases.
concept
We felt that development and operations needed to be delivered to a working system. If the running system hosts running business, the system should not go down. On this basis, we think “who builds, who operates”. Different from the form of cooperation, we emphasize that R&D is more responsible for operation and maintenance, and r&d is responsible for most of the testing work, including on-line deployment, performance monitoring and capacity testing. Operation and maintenance personnel can provide operation and maintenance related tools more professionally.
Concept -> system
The idea from the beginning was to hone the tool chain by continuously delivering such existing open source tools.
The simple architecture diagram above is one of the solutions we do a lot of these days, and after a while we found some problems in it that prompted us to start working on our own tool ecology.
Concept -> System -> Tools
On this basis, we analyzed a lot of tool software is how to do, and also slowly made their own tool chain.
In this process, some problems are constantly mentioned, and we need to repeatedly communicate with the product and r&d.
Why is the system architected this way? Why should software design choose imperfect solutions? Why develop multiple tools for the same question? Why tried-and-true design ideas don’t work?
The commonality behind these issues is what we’re going to talk about today, how to build an easy-to-use tool chain.
The most crucial is the word “yi”, which stands for two meanings. The first meaning is simple. The architecture of the tool design itself should be simple enough so that it is easy to expand and work with each other.
The second meaning is ease of use. Users should be able to solve problems quickly without causing too much burden when using it.
What I want to share today are the problems we encountered during DevOps landing and toolchain development and the thoughts and actions we took to solve the problems.
Why is simplicity and ease of use so important?
If we look at it in terms of the user experience factor model of the product, when we talk about ease of use, we all know that because as users we use different Internet tools every day.
But when we talk about 2C and 2B, their ease of use is entirely on two levels.
2C emphasizes that users should try to reduce the things they think about and make decisions, and keep the stickiness. But 2B talks about how it directly affects the efficiency of solving the obligation problem.
Business and user issues can directly affect simplicity in terms of architecture, design, and interaction.
The deployment pipeline generates binary packages only once at a time, and the test or operations personnel manually select the required version and deploy it to the appropriate environment. Operators should be able to see all builds and their status (phases passed, included changes, submitted comments, and so on), all in order to get feedback as quickly as possible. You must be able to see which versions are deployed in each environment and establish traceability throughout.
The technician is the user of the whole tool chain. Their characteristic is to think highly of themselves, but some things have very low standards – can be used on the line; Can process a lot of information in parallel, but take some things very seriously.
experience
Experience a
Implementation level separation, service integration.
Separate concerns and develop independently. Some systems have their own complexity and can be integrated through views if necessary.
When we do systems, we do one thing and do it well. The advantage of this is that 10 systems doing 10 things is better than one system doing 10 things because of the lower complexity.
One-stop systems are mostly anti-human, giving a one-stop view only when really needed.
Experience in two
Separation of concerns required by design.
Experience in three
Experience in threeAt the design level, including architecture, software design, etc., simplicity is more than perfection.
There are four options for updating the rosters.
Plan 1: Pursue the accuracy of personnel information, regardless of historical information. IPD personnel deletion, personnel scheduling information adjustment, no historical information.
Scheme 2: No real-time query, historical data run batch precipitation. The data within the sedimentation stage are still inconsistent.
Plan 3: Modification is precipitation.
Scheme 4: Shorten the precipitation period and narrow the scope of data errors.
Which is better, Plan 3 or Plan 4? It depends on what the appeal is, but when we actually do it, we choose option 4.
Experience in four
Be sure to pay attention to advanced use when building toolchains. DSL command-line tools are more scalable and efficient.
Be sure to avoid the temptation of scripts when providing command lines. Scripts should not be part of the system if their processing is not atomic to the business.
Experience in five
Just work. When you use a TV or remote control, focus on how you use it, not the logic behind it.
At this level, the comparison of the two interfaces shows that the biggest problem with the upper interface is that the process exposes too much of the internal implementation details, while the lower interface focuses only on the key phases.
Another huge problem with the interface above is that testing passes and manual testing are at two levels of abstraction, where you don’t need to know too much detail and the key stage is what happens. So we should present an interface like this.
Experience in six
Focus on the present. If you are deploying, you only care about the last time it happened and the historical list can be hidden for now.
Experience in seven
Hide non-critical information. During the process of use, the details are only paid attention to when something goes wrong. The whole tool chain is very rich in information, so as long as the error of the time to remind, inform the details of the information.
Experience in eight
Business as a line, do not stack functions. Project as a unit, the file as a basic component of debugging, development and editing.
Experience in nine
Highlight use, separate configuration. When using a toolchain product, 10 percent of the time is spent configuring the workflow, and once it’s configured, 90 percent of the time is left unchanged. If the tool has a “more used, less used” feature, focus on the used parts, simplify the configured parts, hide the functionality, and slowly peel the configuration away.
Experience in ten
Simplify operations. The whole 2B tool chain development is to solve the problem of efficiency. One of the major issues with DevOps is that if every build produces a release, and every subsequent test launch is based on that release, you need to check the status of the entire lifecycle.
So we need to set up a system to track the whole process.
DevOps isn’t as complicated as you might think, but it’s not as simple either.
That’s all for today’s sharing, thank you!