- 原文地址：Moving to DevOps: what tools do you really need?
- Original author: June Jung
- Translation from: Nuggets Translation Project
- Permalink article: github.com/xitu/gold-m...
- Translator: Starrier
- Proofreaders: suhanyujie
DevOps solution is the latest in a series of problems, solutions to every problem, there are many digital tools library: CI / CD system, test frameworks, monitoring tools and security auditing tools. What are the tools you need? Which can solve the problems encountered by your organization, pain points? When teams of all sizes, two questions I often hear is, "We need to have what kind of organization structure? What tools should we use?"
These two are not considered a problem, but when asked individually, they do not seize the key to ask. In direct you to answer these questions, you should first assess your organizational issues need to be resolved, then consider solutions.
Organizations often think top-down mode ( "Using this! Do that!") Their team will make faster innovation. Excellent team leadership will bring a new CI / CD tool, so that everyone can work on the remainder. When competent team leader in the introduction of new CI / CD tools will ensure that everyone can master and use it. The team leader in the introduction of the tool when not fully understand its value, or why do case, the problem arises. There may even be people began to make a change to have forgotten the original intention of using the tool, expected benefits obtained. Regrettably, once the mind is forgotten, it can easily lead to abuse tools, resulting in the loss of all aspects, as well as a negative value.
We need DevOps!
I learned a lot confirm DevOps solution is to organize all of their problems, as long as they can be up and running quickly.
If you are in this position, ask yourself, "Why use DevOps in the organization? We want it to bring any value to us."
At this point, we discuss under what DevOps is and what is not.
DevOps is to develop specific cooperation programs between the team and the operation and maintenance team. In essence, it shows you have applied in practice on the development of culture to your infrastructure and apply to your development cycle in practice. What is the effect of it in practice? This may mean that the base is set as a code to maintain, or to create immutable infrastructure by building reusable components, so that you are free to delete or enable them to provide version control and change history. This also means that all of the products contributors are more concerned about the end result of their work - how they work? How users interact with them. So that means that people care about the quality of care and the availability of its commercial value. When everyone finally build the product concerned two aspects of quality, after the deployment of what will happen and what happens when exposed to the end-user, this is the real purpose of the use of DevOps.
In my experience, this broad support for software teams, is particularly difficult, because it requires from people with different skills and expertise in the field of cooperation. To do this requires both cross-functional team structure, communication skills also need careful consideration. For example, if you need to discuss work issues with the database business people, then he not only needs to inform his data being processed, but also gives the necessary background to the problem, and to focus attention on the person and what they should be concerned the reason.
Should the introduction of new tools? Perhaps the answer is: Maybe. Tools sometimes more like a quick fix rather than a universal solution. In my experience, the introduction of new DevOps tools before , remember these precautions will increase the chance of success.
Before you begin the transition:
1. ensure consistency for all opinions . About you trying to achieve the purpose of this change idea, everyone should agree on this issue, and have resonance at the point of pain.
2. Slowly begin . Do not let this delusion organization overnight become the team DevOps model. Instead, a team from the beginning to see changes in approach, and whether it is more suitable for your organization. If you see a positive improvement, we can either keep trying to improve.
3. understand what you have to do the work . To understand, DevOps may not be the solution to your problems properly organized scheme. Some companies in the absence of DevOps cases were successful, taking into account their culture and products, which may not apply to them. I personally feel waterfall workflow will be more suitable for those organizations successful. For example, if confidentiality is an important part of the company's product strategy, then delivered incrementally to get feedback for you, it will not work, because until the release, you will need detailed information about all products are blocked, until a major release. In this case, the construction of DevOps culture will be extremely difficult.
4. guarantee measure . Before you begin any improvement plan, please contact your current physiological state (ie, the length of the development cycle). Before entering invite SRE development team, please do so. After some time, you can see if it is valid. It is measured before and after you make a change to see if it has changed. For example, when a number of agile transformation, many companies adopted standups, but did not really understand the reason, it did not measure whether their team had a positive impact. This may lead to a waste of time even more than the time saved.
5. Not all things are suitable for automation . At least not at once make the transition to full automation. DevOps is a misconception that all the infrastructure and automate configuration management must be completed. These are called "Infrastructure as a code." But some things manually effect will be better. The method does not solve all the problems of automation. Consider, you will run the automated script how many times and how much time you need to automate. You'll frequently use automated or only occasionally? Sometimes, you must manually, or even to find out what is the best automation solutions. Still eager to automate it? Let the application of the Docker, is an excellent automation solutions, as a result of your efforts to pay can be reused. Automated pre-production environment is another good way to automate. Again an example, if you tried to automate firewall settings? Given the current lack of API support of many firewall software, such attempts may not be worth it. Although for disaster recovery is so meaningful, but in fact, the value you get from that, it may be far less effort you give.
what's next?
If your organization is considering whether to use DevOps, please consider your questions to the speed and quality of products. What is the real problem is that you are now experiencing? Understand the answers to these questions will help everyone to understand your organization's current pain point is located, to help you in the most correct place to change them.
In the following article, I will through some practical help you discover the problem is now to organize themselves , to help you assess which tools to improve treatment methods or self-confidence to solve these problems is the optimal solution.
If you find there is a translation error or other areas for improvement, welcome to Denver translation program to be modified and translations PR, also obtained the corresponding bonus points. The beginning of the article Permalink article is the MarkDown the links in this article on GitHub.
Nuggets Translation Project is a high-quality translation of technical articles Internet community, Source for the Nuggets English Share article on. Content covering Android , iOS , front-end , back-end , block chain , product , design , artificial intelligence field, etc., you want to see more high-quality translations, please continue to focus Nuggets translation program , the official micro-blog , we know almost columns .