Abstract: The problems cover the key doubts and difficulties in DevOps landing practice, such as planning and design, development integration, testing, deployment and release, operation and maintenance monitoring.
“The value of DevOps is delivering software quickly and well.”
— Gene Kim, author of the phoenix project, and JezHumble, author of continuous delivery
In the current situation of digital transformation, the software industry is facing huge market opportunities, and the increasing complexity of software systems, efficient cross-regional collaboration, multi-environment deployment and other issues are becoming increasingly prominent. DevOps can help enterprises improve the efficiency of software development by automating the process of “software delivery” and “architecture change”. To build, test, and distribute software quickly, frequently, and reliably.
Based on this, two expert teachers, Yao Dong and Bu Handong, were invited to answer 60 questions covering the key doubts and difficulties in DevOps landing practice, such as planning and design, development integration, testing, deployment and release, operation and maintenance monitoring. We hope that through these questions and analysis, Help more DevOps practitioners solve the confusion and pain points in the process of DevOps landing. (Click the downloadable PDF document of outline mode for easy viewing)
1. Huawei End-to-end DevOps overview
Q1** : How does Huawei’s end-to-end DevOps tool chain support agile and DevOPs-related concepts and methods? **
A: The concepts of Agile and DevOps are actually similar. DevOps can be seen as an extension of Agile. Agile ideas break down the barrier between requirements and development, while DevOps breaks down the barrier between development and operation and opens up the whole software delivery process.
Huawei Cloud DevOps Tool chain DevCloud covers a series of steps from requirements management to code hosting, construction and deployment, and testing, covering the entire software development cycle. Ideas often need to be combined with practices, and DevCloud can be used for requirements management, daily site meetings, and many other agile practices. Submitting code can trigger an execution pipeline and allow developers to focus on development.
Q2** : What are the differences between Huawei Cloud DevCloud and the traditional tool chain based on open source components? **
A: Most of the traditional tool chains composed of open source components use Jira for demand management, Git for code hosting and Jenkins for DevOps development. Since most of its components are open source, the cost is generally low or free. The disadvantage is that users need to master many tools. And these tools are not on the same platform. Huawei Cloud DevCloud is a one-stop software development platform, enabling all tools to be integrated on one platform, end-to-end coverage of the entire software development lifecycle.
People who use Jenkins know that they need to build a Jenkins environment before using it, and also need to do some customized scripts and configuration, etc. Huawei Cloud DevCloud is like a packaged DevOps development tool, which can greatly reduce these operations.
In Huawei Cloud DevCloud, atomic operations such as compilation, construction, and deployment tasks are made. If we want to do Tomcat deployment, we can directly use these templates. We only need to make minor adjustments to the steps in the templates. It also uses a visual view, which is easy to operate and cheap to learn. Huawei Cloud DevCloud also supports code checking, custom shell, Python, scripts, and custom report presentation.
Q3** : ** How is DevOps/Agile different from SDLC?
A: DevOps/ Agile has A different perspective than SDLC. SDLC refers to the system life cycle. Several typical life cycle models proposed by SDLC include waterfall model, rapid prototyping model and iterative model. Agile breaks down the communication barrier between requirements and development. DevOps breaks down the entire software delivery process.
Q4** : Will DevOps people take on more development, testing, operations and maintenance in conjunction with the project? **
A: DevOps doesn’t involve more development, testing, operations. There’s a concept in DevOps: developers focus on development, testers focus on testing, operations focus on operations, and all of the tool-level stuff is handed over to the tools, just automate everything that can be automated, and all of the people do what they’re doing.
Q5** : What are the anti-patterns of DevOps? **
A: Refer to 9 Types of DevOps Team Structure and 7 Anti-Types
Q6: What industry business models does DevOps fit into? Does the model need to be adjusted for non-software industries?
A: Whether DevOps or Agile, the original ideas and concepts are applicable to all industries, but each industry has some discount in implementation and actual implementation, such as continuous delivery of production environments, automated deployment, quality control, automated flow of processes, etc.
In short, some applications on the Internet, or SaaS applications, are better suited to the DevOps model. The reasons are as follows: its business has high requirements for software update and release; Not too much historical baggage; It is relatively easy to target target audiences, including the production environment.
Traditional classes that are heavy on business, such as core systems for banks, are relatively difficult to practice, not that you can’t use Agile or DevOps. Continuous integration, multiple builds per day, multiple commits, automated testing, visualization, etc.
For non-software industries, such as hardware, embedded, mechanical classes, it is also difficult to practice, such as test automation, etc., need to do some tools or platform adaptation, the introduction of plug-ins or tools, the process can also run, but will be slower.
To sum up, I believe that Agile and DevOps themselves are a road to nowhere, and that all industries can take this road. It’s just a matter of how hard it is and how far it is.
Q7** : Is there a formula for DevOps landing in an enterprise? **
A: There is no universal formula for DevOps, but there are some suggested ways. DevOps is more engineering oriented, and it is usually recommended to establish version management first, such as Git repository, code branch management, etc. The next step is to build up the pipeline and gradually automate testing, layer testing, and so on.
Q8** : What are the most effective practices for continuous improvement within Scrum teams themselves? **
A: Every team has different problems. If you must find A common answer, first of all, ensure that the team’s daily station meeting, review meeting and so on are carried out as scheduled in order to maintain continuous improvement.
【 II. Continuous Planning and Design 】
Q9** : What is the first level of DevOPs-based sustainable planning? **
A: First of all, you need to understand what DevOps and Agile mean. When we talk about planning and design, we tend to refer more to the requirements and plans covered by Agile project management.
Narrowly defined as CI/CD, continuous integration and continuous deployment, DevOps is engineering oriented. The broad definition of DevOps, DevOps in this boot camp, is “end-to-end DevOps,” extending from continuous integration/continuous deployment forward to the business side and back to the operations/operations side, thus covering the requirements and design aspects of the front.
Back to the problem, based on the enterprise realize sustainable planning effectively, should be cut from demand and plan, including the market analysis, the target customer groups of users, the user’s pain points, according to these pain points provide what kind of functions, and then to the product should be how to design, then truly fall to research on this subject.
From the perspective of methodology, requirements and design methodology includes design thinking, lean entrepreneurship and so on. Once the requirements analysis is done, the requirements need to be broken down and prioritized to be incorporated into the Agile project plan, with methodologies such as Kanban, Scrum, and large-scale team Agile frameworks such as SAFe.
Q10** : Scrum, Kanban and ** XP are specific methods of agile development, can the teacher explain the differences in detail?
A: See the article DevOps VS Agile: Stupid Can’t Tell the difference.
Scrum and Kanban are more focused on team-level agile project management, while XP is more focused on engineering practices.
A comparison of Scrum and Kanban: “Standard” Scrum includes 3355 frameworks; Kanban is derived from Toyota’s lean production. Behind kanban is the lean idea of quickly exposing problems and bottlenecks through visualization, limiting wIP, focusing on fixing the most serious bottlenecks, and then looking for the next bottleneck.
Many of DevOps’ ideas also borrow from lean, and I think kanban can be applied to many areas. In addition, Scrum and Kanban are not in conflict when implemented or applied and can be used together.
Q11** : What roles or parts of an enterprise’s organizational structure are appropriate for DevOps implementation? **
A: There is generally no organization within an enterprise’s organizational structure to implement and deliver DevOps. DevOps consists of two parts, Dev and Ops, which are development and operations.
Several common situations:
· If DevOps is initiated by the development department, it is promoted from development to operations. We usually see the test team or the traditional quality management department to initiate, from development to testing and then to the operation and maintenance production environment, because these departments themselves undertake the code hosting, build, automated testing and other functions.
· Some companies put their internal infrastructure, IT support, testing, etc., in the data center, and push forward to become DevOps engineers like we talked about, and then help the development team with automated deployment through automation tools. This is pushing DevOps forward from the operations side.
· Another situation is cloud native, which is popular in recent years. Architects are more likely to adopt microservice architecture and automatically deploy it into Docker environment by means of infrastructure-as-code. Therefore, practices such as automated pipeline, Infrastructure as Code and interface test are introduced. These are all DevOps.
· There are other roles, such as Agile coach, internal technical coach, etc., who are doing the ground practice of R&D management themselves and naturally transfer to DevOps promotion.
To sum up, DevOps does not necessarily require a DevOps engineer or an independent DevOps team to promote and land DevOps. When DevOps is initially introduced, it is necessary to have a team or role to assume the responsibility of introducing and exploring concepts and practices, which makes it easier to establish DevOps engineers and DevOps teams. At a later stage, these engineers or capabilities should be spread across teams to allow DevOps to be more widely spread and practiced throughout the enterprise.
Q12** : in Scrum, if there is no project manager, do the TeamLeader or ScrumMaster coordinate the resources? **
A: the TeamLeader should coordinate the resources. The ScrumMaster is not A management role, but more of A supporting sheepdog role, guarding the team Scrum process during Scrum implementation.
Q13** : For non-product projects, which department is the Product Owner from? (Business department ****/** R&D Department)
A: The Product Owner represents the customer. Generally, the person in the department is the one who is closer to the business and knows more about the business and system. The Product Owner of a non-product project must understand both business and technology. Generally, the Product Owner can be a business analyst or PMO.
Q14** : In actual development, customers often do not assume the role of PO, but the leader does. How to solve this problem? **
A: This situation is called “BDD”, boss-driven Development. The advantage is that at least one person can make the decision; The downside is that the person who makes the decision may be difficult to argue with or negotiate with, so it’s best to bring the person on the client side in. Of course, if the boss really knows the business, is very professional, and is a person to communicate with, that’s fine, too. The core requirement of a PO is to have a person who represents the customer or the business side to make decisions about requirements or scope, and who is always available when the team has a problem.
Q15** : Where is the impact map mainly used? **
A: As you can see from the HE2E DevOps implementation framework, in end-to-end DevOps practice, impact maps are usually used in the requirements planning or business planning stages and are more business-oriented than traditional Scrum processes. Impact maps break down business and requirements through a four-tier structure: Why, WHO, How, and What, and can also be used for operations or project cold launches.
Q16** : If a big Story is split into several smaller stories, or even the Story of grandchildren, how can these relationships be better represented? **
A: There are two ways to split the Story. One is to split the Story from epic (epic Story) to feature to Story. Epic is divided by month, feature by week, and Story by day. The other is a horizontal split, where all the stories are called stories, but they have a parent-child relationship. We only focus on the parent-child relationship, splitting a parent story into child stories, and if the granularity is not small enough, splitting the child story into its child stories. If the system needs hierarchical traceability, it can be represented by structures such as trees or brain maps.
Q17** : After finishing the course, I feel that user stories are similar to work packages in project management. They have a common problem: what granularity is a good user story? **
A: Story or demand is just A name. The reason why A user story is called A user story is characterized by two aspects: 1) It is viewed from the user’s point of view; 2) It tells a story, a scene. Good stories follow the INVEST principle, A proper user story should be Independent, Valuable, Testable, holder, Small, Estimable and Testable.
Q18** : How will the end user requirements be presented to the user if agile development is adopted? If it is a user specification, design specification, or operation manual that needs to be archived, is it appropriate to export it from DevCloud and then modify it? Also, if changes occur, how do you ensure that the documentation is consistent with the code? **
A: If it is A requirement document, it can be stored in the form of A user story. Huawei DevCloud or other tools provide multiple storage formats, such as text, pictures, attachments, etc. Huawei DevCloud has A help website, where each newly launched function will be synchronized and updated.
You can also put terms or requirements in a wiki and link them to the previous requirements. The wiki itself can be hierarchical, with requirements exported from the wiki to form a document. If done well, there can be a release plan, such as 10 requirements in the release, which can be exported in one requirement specification document.
Synchronization between requirements and code can be controlled through processes, such as checkpoints for releases, which may need to be done manually, but can also be assisted by tools. Need to submit a comment when submit code, for example, can put the comments associated with a work item, a demand may modify more code in multiple files, this is a complete change sets, the concept of the change is for the same purpose, there is a correlation of, if want to divest from the code, it should be unified change of this time to set in. When you look at code in the future, you can compare code versions to see what additions/changes were made between the two versions, what the purpose of the changes was, and what their intent was.
Q19** : Should changing requirements or new requirements be placed in the current iteration or planned for the next iteration? Does continuous planning refer to the planning process throughout the life cycle? **
A: Changed or added requirements are aggregated into A large pool, which we call the Product backlog. It is A one-dimensional table with all requirements arranged in order of priority. We need to prioritize new requirements to see where they should be placed. Agile emphasizes that requirements change dynamically, and we regularly review the list of requirements to see if it needs to be prioritized,
Therefore, changes or additional requirements will not be placed in the current iteration, because the current iteration is a fixed time window with a relatively fixed scope that the team has committed to. We put it into a large requirement pool, implemented in the next iteration or later, depending on the priority of the requirement.
Q20** : How to start with Agile for beginners who have just started a project, but the requirements of the project are not clear and the structure is not mature? **
A: There are two situations: beginner and project in the initial stage. If you are a beginner, you should get used to it quickly by acquiring existing assets. If the project is in the early stages and the requirements are not clear, quick feedback can be obtained through practices such as agile fast delivery and lean MVP to provide guidance and suggestions for the follow-up work.
Q21** : As the entrance of the whole project, how to control and evaluate the quality of requirements? **
A: Clearly define the standards by which requirements can be transferred to development, the DoR. So what is DoR? After several years of agile development, people found that certain conditions should be met to enter iterative development. Otherwise, too vague requirements would lead to the failure of the iteration, and too much time would be spent to clarify requirements in the iteration. Therefore, the threshold to enter the iteration is defined as Definition of Ready, which is simply called “DoR”. Originally Ready meant Ready for iterative development.
Q22** : What metrics or indicators are available for continuous planning and design to measure team performance or for continuous improvement? How to measure the maturity of continuous planning and design? **
A: The measurement tool recommends the Scum burnout diagram and kanban cumulative flow diagram. Core metrics of R&D effectiveness include team speed and Lead time, which is the average delivery time of requirements.
Q23** : Are there good storage solutions for organizational process assets (configuration, documents, etc.) under Agile? **
A: Theoretically, documents and assets are stored in the Asset database. Common knowledge bases or Asset platforms include Conflunce and Rational Asset Manager of IBM. Assets and knowledge are different concepts, and there are relatively few assets management now. Knowledge base can be maintained, updated and coordinated through wiki and other platforms.
Q24** : Continuous DevOps planning and design is at the beginning of the DevOps lifecycle. Why is code integration central to the entire DevOps lifecycle? **
A: code integration consists of two parts: code and integration.
The software life cycle consists of three versions: requirement version, or release plan; Code version; The version of the binary package that is released online. The code version is in the middle and the only one that really counts. Requirements and documentation are worthless, only code compiled into binary packages and deployed online. It’s important to put a little extra effort into the code side. All development is done collaboratively in a code repository, including code versioning, branch management, etc., so it’s necessary to treat code as the core of the DevOps life cycle.
The most painful part of software development is often at the integration level, where everyone starts writing their own code, and when it comes time to integrate those different pieces of code, problems arise. The concept of continuous integration comes from XP: “If code integration is a pain, let’s do it multiple times a day.” Whatever doesn’t kill you makes you stronger, keep integrating, and you’ll find ways to make integration less painful. Just like running, if the previous integration is a big stone, daily integration is equivalent to turning the stone into a small stone, the big stone will be very painful in the body, the small stone is much better. This is why it’s important to keep integration in place and to keep it going, so continuous integration is important throughout the DevOps life cycle.
【 III. Continuous Development and Integration 】
Q25** : How can I enhance developer confidence in release quality? **
A: Build confidence in release quality, not just for developers, but for everyone. The whole DevOps process is about ensuring overall release quality, including static code inspection, interface AND API testing, etc.
On the other hand, the mapping or completion of the version to the requirements should be cut down from the business scenario to see how well the overall requirements match.
The third point should be what we usually call non-functional requirements, such as load, performance, security, concurrency support, etc., which are based on the quality of our service promises.
Q26** : What are the advantages of Agile development over traditional development? **
A: I think the biggest advantage or characteristic of agile is that it is more authentic, or it is more willing to acknowledge the nature or status quo of R&D.
Traditional R & D believes that quality is restricted by three factors: scope, resource and time, and the default scope and resource investment are relatively fixed, and time is variable. However, in the real scene or changing market, time and resources are fixed and there is no way to bargain, because the market, business and customers will not wait for you. Under this premise, the demand or scope of software can actually be discussed or discussed. We need to win the market and time window with variable scope.
Agile development requires us to continually deliver high-priority requirements and get feedback to adapt. This is the biggest core of agile development, recognizing that markets are fluid and the range of requirements variable.
Q27** : A product, both the main line version, but also a lot of industry custom branches (50+), what branch strategy is suitable? **
A: This kind of scenario is common in traditional products. I think it is product strategy rather than branch strategy that should be considered. If there are too many branches, the product will become fragmented.
In continuous integration and continuous delivery, we advocate trunk development or short branches. We do not want these branches to exist for a long time, otherwise it will be very painful when merging products, and the workload will increase geometrically with the number of branches and the duration of branches. Therefore, we do not recommend using long-term branches.
So what kind of way can it be solved? The first thing to look at is whether there must be so many custom branches throughout the release, and whether these branches can be handled or implemented through configuration files, feature opening, and so on. For example, in our project management software, the fields and function flow required by each customer are different. If they are all realized by code, there will be as many branches as there are customers, and there may be more than 50 branches.
So how did we do that? For fields, I can configure an interface that includes fields for common attributes, which can be text type or drop-down box, etc. Function, in a new demand, what is it the next state, what action should be triggered, what kind of role should be to trigger the action such as these can be configured, the database configuration information are present, into a user configuration data, so my main code of the main program is unchanged, Just provide a set of models to drive adaptation or implementation based on the data. This is the preferred way to eliminate those branches.
Q28** : In daily project development, I often wonder which branch management strategy should be used in code branch management, such as production branch workflow or environment, etc. In practical practice, what factors should we focus on? Both management efficiency and code quality can be taken into account. **
A: I recommend the branch management strategy of branch development trunk publishing or branch development branch publishing. When building branches based on the environment, we used to have the concept of development library, test library and other warehouse management, but now it is all continuous integration, automatic deployment, there is no need to pull branches based on the environment.
To ensure code quality, we need to consider what tests to run on each environment as we streamline CI/CD, automate deployment and build. Most of these tests are automated, but a few are manual.
Q29: What branch management mode does Huawei Cloud generally adopt when its team members are strong and its application scenarios are mainly online services?
A: Huawei cloud team also adopts the feature branch management mode, and makes multi-stage production lines to trigger the production lines of different environments for relevant construction. In addition to the production lines of development environment, there are also production lines of testing and class production environment.
Q30: What are the requirements for the development team and infrastructure to ensure that the submission on the trunk is always in a releasable state, free from the influence of hidden code conflicts and submitted features that are only partially completed?
A: First of all, the process or quality submitted on the trunk should be strictly controlled to truly meet the Definition of Done (DoD) standard. Some mechanisms, such as Committer mechanism, may be required for control. At the time of submission, in addition to non-functional requirements, such as running relevant regression tests and code reviews, there are also important functional requirements, such as checking the implementation of requirements. “Infrastructure is code,” and it depends on continuous integration, continuous deployment, and automated testing to run quickly and efficiently, with a high degree of consistency.
Q31** : What are the success factors of continuous integration? **
A: Continuous integration mainly includes four aspects: code warehouse, automatic construction, automatic deployment and automatic testing. Continuous integration is successful by requiring everyone to commit code to the trunk every day, triggering automated builds and deployments, automated testing in the class production environment, and ensuring that every member of the team is aware of what is happening.
Q32** : What is the difference between CI/CD on Huawei cloud and CI/CD on K8s? **
A: Huawei Cloud DevCloud opens the whole process of end-to-end software delivery and integrates common DevOps development tools. It can not only complete CI/CD, but also directly carry out project management and development on it. However, K8s is only a separate tool in software development, without project requirements management and other functions, and needs to be used together with other tools to achieve complete software development and delivery.
Q33** : How to arrange the working hours of developing and fixing bugs? Are the bugs of previous iterations arranged separately or uniformly in the development? **
A: It depends on the standards and requirements of the version. Generally speaking, you can have A version with A disease, but if it is A very serious defect, you can’t go online. You must fix these bugs first. Generally, bugs and requirements will be placed in the same pool, and sorted according to their priority and impact degree, deciding whether to fix bugs or do requirements first. If bug fixes are intended to clear technical debt, it is recommended that you spend a fixed percentage of your time in an iteration.
Q34** : Which is the best configuration management (CM) tool between SaltStack and Ansible? Why is that? **
A: They are positioned differently. In my opinion, Ansible is not a standard configuration management tool, it is more of an automated deployment approach to the Touch environment, SaltStack is relatively more functional.
Q35** : How to effectively improve code quality in the code mutual review and review process? **
A: Man-machine integration, leaving repetitive work, such as checking code style and naming rules, to tools; Manual focus on the logic of code practices, matching requirements, and so on. It frees people from repetitive work and saves time and manpower.
Huawei implements code review Committer mechanism. After developers submit codes, automatic code check is automatically started. A Pull Request is submitted, the tool is reviewed and scored with relevant reviews, and maybe a review meeting if it’s a significant implementation, and then a final Committer decides whether to incorporate the submitted code into the trunk.
Iv. Continuous Testing and Feedback
Q36** : **** “Fast and high quality through continuous testing” ** is one of the principles of agile testing, and some tests at the top of the test pyramid tend to rely on many external factors, which are fragile and easy to fail due to factors other than the software under test; And because such tests test multiple modules in the software at the same time, it is harder to locate problems. What’s the best way to deal with Flaky Tests? Delete or mark it so that it does not interrupt subsequent testing and does not affect the quality access control?
A: Flaky Tests are Tests that sometimes fail and sometimes succeed, with the same subjects and conditions. Thus, Flaky Tests are essentially unstable Tests, or Tests that randomly fail (randomly succeed).
Test is right in the triangular pyramid, the core idea is up, namely the test at the top of the pyramid, the span, the greater the influence surface is larger, once appear problem, explosion radius will be bigger, at this level do test input and output is small, big workload and it is difficult to perform, such as testing fault location, and automation degree of reuse cases or stability also is bad, Maintenance costs are also high. Of course the work must be done, but relatively speaking, it is recommended that the number of tests at this level be reduced.
Conversely, lower levels, such as unit testing, tend to have smaller blast radius, higher reuse and input-output ratios, and the highest number of bugs found at this level. ** Suggests that more testing measures should be taken at the bottom of the pyramid.
In the middle, such as interface testing or cross-component integration, if the micro-service separation is relatively granular, all aspects are relatively better, and there are more corresponding tools for interface testing, and the input-output ratio will become larger and larger. Interface testing can also be done more, so that the middle layer is bigger and the pyramid is shaped like a football.
Q37** : How easy and costly is it to build on-premise continuous testing versus on-cloud continuous testing? **
A: The difference between on-premise continuous testing and on-cloud continuous testing is that tools and releases need to be maintained locally, while the cloud environment is relatively fast. In terms of cost, cloud is on-demand. Performance testing, stress testing, etc., are suitable for cloud, because it is very expensive to build a set of 100,000/1,000,000 concurrent environment. The farther forward end is tested very frequently and is suitable for building locally. In addition, it is necessary to consider the usage habits of developers and data security requirements of the company.
Q38** : What exactly is the difference between traditional waterfall testing, agile testing, and DevOps? **
A: Waterfall testing is A complete test conducted after the development is completed and delivered, and the testing subject is the tester; Agile testing goes a step further and does a lot of continuous integration practices (if agile practices are not just at the management level); DevOps is full process testing, testing left move, testing right move, frequent and continuous deployment to a quasi-production or production environment to run related tests, and even live network testing, including Chaos engineering, Chaos Monkey, etc. The concept is broader. DevOps believe Resilience, testing is a painful thing to do, and we have to do it often. In line with the concept of anti-vulnerability, “What doesn’t kill you makes you stronger.”
Q39 in the test automation link should be how to simplify the testing process and quickly find business risks?
A: The testing process may not be simplified. The so-called simplification should mean that the process of personnel participation is reduced, and A lot of work that can be done by the machine is handed over to the machine and regression testing to achieve automation, freeing people from boring and repetitive testing activities and exploring some new tests.
Q40** : What are the differences and connections between SRE and DevOps? **
A: DevOps is usually initiated by two roles, Dev and Ops, development and operations.
SRE is a concept first proposed by Google, Site Reliability Engineer (Site Reliability Engineer), a role from The Google operation and maintenance system.
SRE engineers help developers with automation tools, participate in r&d and provide support from an operations perspective, including developing automated deployment and operations related tools and enabling developers through these tools and processes.
DevOps has a larger concept and scope than SRE, which focuses on development and operations.
Q41** : There is only ** Dev Team ** in Scrum, there is no dedicated test team. **** “Testers are better than checkers” ** also requires testers not only to find problems but also to locate them accurately. Continuous testing extends to both ends of the value stream and requires testers to understand not only business, development, but also operation and maintenance, which has high requirements for testers. In this context, how can a tester plan for career development?
A: It is true that testers have more anxiety, because no matter the process or the division of roles, they are in the position between development and operation, like A sandwich, which is uncomfortable.
On the other hand, testing is a link between the past and the future. DevOps or Agile starts out relatively smoothly, with quick short-term results, but when you get to the testing level, it’s like getting into the deep water, and it gets harder, probably because of poor automated testing. There is a lot to be said for testers or testing activities, and we emphasize that testing should be one type of activity that is distributed throughout the development life cycle, not just in the middle, and therefore more demanding of testers.
In the past, testers had the impression of being involved only after development had been submitted, or doing regressions with a lot of manual interface clicks. Now and in the future, the value of such testers will be very low. In the future, testers may be required to understand the business and design test cases from a business perspective. Also know development, need to write test scripts; Also know operations. In fact, these requirements are the same for all engineers, including development engineers, who should be able to do architecture, design, development, but also may be able to do their own testing, deployment operation and maintenance; The same is true for operation and maintenance engineers. If you transition to SRE engineers, you also need to move forward. From this point of view, everyone is on the same level, and everyone wants to develop into a T-type talent.
To sum up, the test engineer should be a whole-process quality assurance personnel, who should carry out quality control on the R&D process, requirements and delivery from the perspective of professional testing, and also need to introduce relevant practices, development tools or tool integration to enable development and operation. Really good testing will help and improve the team the most.
Q42** : Is testing a smaller part of the process and more frequent in agile projects than in traditional projects, and does that mean more human efficiency? Is there a new lesson in the ratio of product to developer to lead tester in the DevOps process? **
A: Compared to traditional projects, agile projects have more testing effort, more frequency, and more human efficiency, but this increase is not done by people to the heap, but by automated tools or time. Under the DevOps process, the number of professional testers will decrease. Now a large number of development tests are done by developers, which is called developer testing in Huawei, emphasizing that developers do the tests themselves. The ratio of development tests used to be about 3:1 or even 1:1, but now it may be 5:1 or 10:1. Product personnel should not be too different from the past, now emphasis on product thinking, operation thinking, the number of business operation personnel will increase.
Q43** : Small team (5 people, division of labor: 2 front end, 3 back end, no professional testers) do you need separate testers, testing as you develop, or is each person responsible for the last piece of centralized testing of their own code? Which of the two is better? **
A: PERSONALLY, it is not necessary to configure full-time testing for A 5-member team. The developer can take the test first, and then introduce professional testers when the team thinks it needs A professional test to know or support. Who’s going to do the end-to-end testing? The suggestion is to adopt a rotation mechanism, similar to on Call, and let team members take turns to do it, so that everyone can understand and pay attention to the complete test.
Q44** : Will there be integration in the future? **
A: I think there’s going to be A trend towards integration of research and development, and the percentage of developer testing or development testing is going to be bigger and bigger and it’s going to be moving forward,
Social division of labor is close long will points, long period of division, division of big derived some new concept, professional people do professional thing, driven nature of our business is more focused on their own, such as IaaS (infrastructure as a service), ops/environment management, system management will be a professional man to do it, you can see whether you is such a professional talents. The same is true for testing, such as Test as a Service (TaaS), which is also a very professional field, requiring knowledge of development, business, and operation and maintenance. Another is to look at the company’s core business, many companies are not specialized in testing, operation and maintenance or tools, we should focus on the company’s main business.
V. Continuous safety and audit
Q45** : If there is a lack of professional security and audit personnel in the organization, how should we complement this capability? **
A: Some teams will transfer this capability to A related SaaS service platform or third party vendor. However, the platform can only provide the presentation of problems, and the actual security audit processing needs special personnel. When the team size is small, business division and some tools can be used to reduce the pressure of the corresponding personnel as much as possible.
Q46** : Small team security control is too strict, will cause a lot of inconvenience to the development and testing, but also affect the problem elimination tracking, how to measure security control reasonably? **
A: after the project into the normalization process there will be A lot of environment: the development environment, test environment, production environment, production environment, etc., can use more environmental safety control strategy of different level, such as when A development environment test security controls can loose some efforts, class to test the production safety regulation strictly.
Vi. Continuous Deployment and Release
Q47** : Can continuous deployment achieve hot deployment and directly deploy through pipeline without suspending services to provide user experience? **
A: Continuous deployment. Every change is directly deployed into production, but continuous delivery is selective. We can selectively deploy what we need into production. If you want to achieve hot update and hot deployment without suspending services, you can directly use the pipeline to implement continuous deployment.
Q48** : What is the difference between K8s and Docker in application? **
A: Docker is A container technology. In practice, Docker can be directly used for image construction and other operations. K8s is a technical means for cluster management. The help center of Huawei Cloud DevCloud has a practical case of Phoenix Mall, which is the same as the experiment in the HCIP exam, but with more CI/CD links, K8s is used in this link.
Q49** : ** What is the relationship between K8S and cloud native?
A: Cloud native is A concept and approach that includes microservices, DevOps, containerization, continuous delivery, etc. K8s is just A cluster management tool.
Q50** : Is there any way to achieve continuous deployment if the production environment requires equal protection? **
A: If the production environment has waiting requirements and is not suitable for continuous deployment, it is better to use continuous delivery. We can decide which features to move to production first.
Q51** : The new version of the program changes the data structure. How do you design the application or deploy the plan to deal with the version rollback that may be required if a major problem occurs? **
A: When we make some big changes, we usually deploy them to the class production environment first, and then synchronize them to the production environment through grayscale after checking the problem.
Q52** : We’re already doing continuous integration, but what about continuous delivery and continuous deployment? **
A: If you’re already doing continuous integration and you’re mature, it’s relatively easy to move on to continuous delivery and continuous deployment. We often say that continuous delivery is just a small step forward in continuous integration, and the last kilometer or meter is painful. In fact, the most painful point is not the technical level, but the process and system level, it may be difficult to penetrate the department wall, through the requirements of enterprise control, these are not necessarily problems that technology can solve.
[VII. Continuous Operation, Maintenance and Monitoring]
Q53** : Will there be interference and errors in achieving continuous integration and delivery in an automated way? **
A: In general, continuous integration and continuous delivery in an automated manner are less error-prone. The error may be caused by configuration problems, such as parameter problems and version inconsistency. In addition, there may be an unexpected problem, such as network failure.
Q54** : If the production environment requires network isolation, is there any way to achieve continuous deployment? **
A: If the production environment requires network isolation, our pipeline will be built in-house. That is, everything from submitting code to building and deploying will be done in-house. There will be less use of cloud automation products in this process, because most of the tools currently built on the cloud must access the public network to achieve pipelined effect.
Therefore, in this environment, it is recommended to set up an automated build pipeline locally or purchase tools for private deployment. Code can also be hosted and built on the public network, and packages can be manually deployed only at deployment time on a network isolated machine.
Q55** : How is Docker different from virtual machines? **
A: From the figure above, we can clearly see the similarities and differences between Docker and virtual machines. The VM on the left is used by a VIRTUAL machine, and the container is used by a container, which is called a Docker. There are server and Host OS (virtual machine system) on both sides. We know that every APP has Bin/libs. In the environment of Docker container technology, the same APP can share the same Bin/libs. Greatly saving the occupied resource space.
8. DevOps Practice and Transformation Path
Q56** : I’ve learned a lot about the features of DevOps so far, but one question is, if DevOps is zero code, will it slow down code development for professional developers? **
A: DevOps provides zero code, which means that you want to have zero code throughout the DevOps tool chain. By automating everything that can be automated, it frees developers from all the maintenance work and allows them to focus on development.
Q57** : In DevOps practice, where do environmental differences need to be addressed to reduce or avoid? **
A: Configuration refers to code, which includes environmental differences and so on when configuring differentiation in the development process.
Q58** : What were the most challenging aspects of the DevOps transition for the organization and the team? **
A: I think the most difficult aspect of the DevOps transition is how to get top management to agree to the DevOps transition; Second, if a coach/consultant is hired to assist in the DevOps transition, how to maintain and implement DevOps practice after the consultant/coach leaves?
Q59** : If a small team wants to use DevOps, does it need all staff to learn? It seems that the time cost of everyone learning is quite high. Can someone be responsible for specific stages? **
A: If A team wants to make A DevOps transition, it needs A dedicated person to understand the processes and tools, or hire an external DevOps consultant, who can be trained and driven by A full staff or DevOps consultant throughout the team.
Q60: Can you list the difficulties or difficulties encountered in the four closed-loop processes? What are some ways to avoid it?
A: Remember the four closed-loop processes:
· Closed loop of the first stage: integration of requirements development and testing, integration of product, R&D and testing roles, formation of cross-functional teams, and improvement of product delivery value and quality;
· Closed-loop of the second stage: integration of development and testing, formation of cross-functional teams within the R&D department, improvement of automation level, and reduction of repair costs;
· Closed-loop of the third stage: integration of R&D and operation, implementation of self-operation and self-maintenance of products, breaking barriers between market, R&D, and operation and maintenance departments, integrating more roles into delivery links, improving business response, and establishing value feedback flow;
· Closed loop of the fourth stage: the goal is to gradually realize that all business lines take cross-functional teams as the smallest organizational unit, realize business agility, and continuously improve the market competitiveness of the enterprise.
Difficulties include:
· Difficult to get through demand. Communication between the product side and the R&D side is difficult. In the traditional waterfall mode, there are many problems in product and R&D communication, such as unclear requirements communication, etc. The introduction of agile planning meeting and requirements clarification in the planning meeting can solve this problem.
· Difficult to integrate development and testing. In many companies it’s two teams, and in others there’s no testing role, and it’s difficult to mix people and process.
· Difficult to combine r&d and operation. Integration of R&D and operation, how to combine the content of operation with development is also a difficulty.
· Difficult to manage organizational structure. The whole process gets through, and there may be problems with the management of people and the change of organizational structure.
The above difficulties need to be put into practice and explore the best solution according to the specific situation of the company.
This article is shared with Huawei Cloud community “[FAQ] DevOps 8 Areas 60+ FAQs”, originally written by Cynthia Cheng.
Click to follow, the first time to learn about Huawei cloud fresh technology ~