Geekly Articles each Day
📜 ⬆️ ⬇️

Is DevOps afraid of modern QA?



You heard about DevOps, but little idea what it is? Maybe you are a QA engineer and you are afraid that the demand for you may fall due to DevOps? Or are you a developer and want to upgrade yourself and your team before implementing DevOps, but you don’t know where to start? Answers under the hood.

Full-stack Engineer at ZeroTurnaround, co-host of the Russian DevOps podcast “Two Devs One Ops” Sergey bsideup Egorov ( twitter.com/bsideup ) answers the questions .
')
Sergey Egorov:

“... Depla, infrastructure change, lack of knowledge about different parts of the system, transparency of change delivery, local development complexity,“ fighting fire ”after rolling out to combat servers ... for each of them DevOps gives answers and recommendations”

Deploying an Application is a Whole Science


- First, let's talk about DevOps. Why did this ideology become popular in a relatively short period of time? What are its main principles?

- I do not think that DevOps is something fundamentally new and taken from nowhere. People used to do what is considered the canons of the DevOps approach. Coverage is another thing, because if earlier large companies on the proposal of developers to participate in the infrastructure offered them to go to X Server, because it sounded crazy and the risks were extremely high, now, the same people have a very big trump card, and this trump card is experience. The experience of other teams, large teams, the level of IT giants. True, the risks have not gone anywhere, and the chances of "nadovops" - is complete. But, in general, the trend is very good, solving a real problem - the problem of interaction between the team engaged in the development and delivery of the same product.

Difficult to say about the main principles of DevOps. Help each other, or something. Deploying an application is a whole science, and you, as developers, should be interested in your development finding its end user without falling off the way. Take the craftsmen - they are well aware of the mail, sending parcels, the nuances of this process. Because the mere thought that someone would throw their product along the way, press it down, or lose it, terrifies them. So why should we treat our services, which we are developing, badly and not worry about the delivery process?


... about the main principles of DevOps. Help each other, or something ...



- QA is considered to be one of the components of DevOps. Is it correct to compare them with each other as two different methodologies and why?

- warm with soft. DevOps is a methodology, while QA is still the process of getting an early feedback about your product and verifying that the product meets the requirements set for it. Therefore, it is not correct to say “DevOps engineer”, while “QA engineer” is quite a position. Such questions are very easy to answer if the word “DevOps” is replaced with “Agile”. Agree, it sounds silly: "Let's find ajaila!", "And how many ajails in your company?". Hire Agile Trainers. The team follows the Agile approach. And here as well.

- What is the fundamental difference between the DevOps approach and the standard approach in QA?

- From my own practice - in the DevOps approach, people begin to write more integration tests, shorten development cycles. Continuous Delivery is a completely natural process of delivering changes in a DevOps environment, and this indirectly improves the situation for QA, reducing the number of changes in builds that it needs to test. Of course, at the cost of increasing the number of these same builds, but here is a question of balance.


DevOps Methodology

Developer’s work does not end with a commit; it’s just beginning there.


- How does DevOps affect the lives of QA engineers?

- Most often, the QA comes to the build, which has already passed some kind of automatic testing. But integration testing allows testing very tricky cases that QA would be difficult to reproduce. DevOps stands out for all sorts of tooling, and the QA in this issue is also not bypassed. All kinds of distributed build systems, parallelization tests. I know for sure that for some QA engineers, the ability to raise environments for testing as close as possible to combat ones is worth its weight in gold, and this is quite natural for the DevOps approach, what you are striving for.

- Most often, DevOps uses Continuous Delivery, which is characterized by a fast pace of rolling out new releases and deployments. Does this ultimately turn into a “rat race” when one person is engaged in both writing code and testing and administrative functions?

- Well, if you hire a “DevOps-engineer” in your team - it turns. As long as DevOps is associated with specific people - the situation will look something like this, because demand will come from these specific people. But when you have a team “soaked” DevOps, then they are all rolling out. After all, I remind you, the work of the developer does not end with a commit, it is just beginning there. Bring your changes to the end user - that’s everyone’s goal.

- The main tool of DevOps is all sorts of automation. As a result, the launch of such a process becomes expensive. Is there a limit to which the use of DevOps does not justify itself? What does it depend on?

- I think the opposite. DevOps allows you to make a quick start, and then tighten the nuts. Deploy the product prototype an hour after the hackathon with the hands from the developer’s machine with a simple script, and then set up automation, for example. It is very important to follow the approach of MVP - Minimum Viable Product. This is not when "we set up a cool CI service, scaled, beautiful pipelines were drawn, but the build goes through a shell script and javac calls." We need a little bit of everything, and improve when one of the layers of product delivery begins to lag far behind the others.

The main thing is that the team as a whole is able to cope with any situation.


- Does DevOps increase qualification requirements for participants in the process?

- I'm afraid so. DevOps has absorbed a lot of best practices, but not all understand them at a sufficient level. For example, open 12factor.net/ru/ from 2012 and go through these 12 simple items. Very well determines the developer's willingness to go to the DevOps process, his ability to write modern services that are natural for DevOps.

But, there is good news - thanks to the popularization of DevOps, the material is simply unmeasured, and raising qualifications in this is much easier than, for example, 10 years ago.

- DevOps is a seamless connection of several departments. Does this simplify logistics within the company? How does this affect the work of the company as a whole?

- I, frankly, badly imagine DevOps a team of 100 people, for example. It is much more effective to break up departments into small teams, a person of 10, but the teams should be cross-functional, that is, have all the right people for the task. Someone often confuses this with the fact that “every team should have a person in each direction” - this is not so. People are multifaceted in nature, and DevOps only confirms this, so the same person in a team can develop and customize the infrastructure, for example. And the other is a fan of Jenkins plug-ins, and generally well versed in build systems. The main thing is for the team as a whole to be able to cope with any situation, be it the creation of a repository for storing code, setting up a system build, deploying a cluster in production, responding to monitoring system notifications.

- DevOps stands out for its set of necessary tools? What is special about them?

- Well, let the developer deal with the servers, and he will not deal with them. It will develop for servers. The developers ... they are lazy, which means they want to automate everything, so it turns out that with the popularization of DevOps a huge variety of various systems have appeared, or their reincarnation. Here, take Kubernetes - the leader of the orchestration of services, almost no talk about DevOps (including this one) goes without mentioning it. But is this something new? No, Google only implemented “for all” its Borg, which they have been using for more than a dozen years.

Not to mention Docker - after all, nothing new, containers existed for a very long time, but it was the ease of use of such complex systems that made it so popular on the wave of DevOps.

Universal tools do not exist per se. DevOps - it's not just about tools, you can't just say, “take it, this and that - and you’ll have DevOps”.

It depends on your product and environment, in the cloud you or on your servers. I can only say that the clear leader in DevOps tools is automation, both in development and testing, and in delivering changes. There are many orchestration systems like Mesos, Kubernetes, Docker Swarm and others that allow you to work with your infrastructure through the API, they are very helpful in automating the part that is often mistakenly considered “this is DevOps”. Tools that turn your servers into a faceless “flock”, where the problematic server is easier to re-create, instead of taking care of each server separately.

- What problems exist in modern DevOps?

- I think the legacy of the application is one of the biggest problems. “We tried to push our monolithic EAR into the Docker container with WebSphere, and something didn’t go, your DevOps doesn’t work” - quite a popular saying. DevOps helps to avoid many problems in the development, but it does not solve most of them, if they already exist.

I think it's also not easy to find people who would organize a DevOps team effectively. Such people are required to keep up with modern technologies (and without this, nowhere, since most DevOps technologies are young), while having the experience of an organizer. Remember the phrase about the 10x developer? "The one who will help the other 5 to be 2 times more productive." I think this describes very well the people who are promoting DevOps in their team. And it is sometimes very difficult to change the approaches of other people, to convey to them the significance of those changes in the process that DevOps carries with it. True, the result most often justifies the means, and successful DevOps teams most often recall their old process “as in a nightmare”.

- Tell us about how is the introduction of DevOps in the work of the company? How it all begins and how to understand that everything “worked”?

- Each team knows the problems of its process. In the end, DevOps as a concept arose from the problems of the process, the same problems in different companies.

Analyze your product development and delivery process, find the bottlenecks. Deploy, infrastructure change, lack of knowledge about different parts of the system, transparency of change delivery, local development complexity, “fire fighting” after rolling out to combat servers - I think everyone will find a familiar item in this list, and maybe a few. And for each of them DevOps gives answers and recommendations. Successfully solved this problem is a good indicator that DevOps started working for you, not you for it.

- In June 2016 devops.com published an article “How DevOps is Killing QA” , which states that DevOps does not need a QA. How can you comment on this point of view?


Statistics of search requests in Google "sqa jobs" and "devops jobs"

- QA as a process is not going anywhere. Yes, there is more and more automation of testing, it becomes easier to do A / B testing on real users, but that's the business ... The programmer always expects the code to work. Therefore, when a programmer tests his code, he does not expect any other behavior from him, he writes tests to make sure that his code works. A good QA engineer, in turn, does not see the code, he sees the product, he thinks about what can be done with the product, what is wrong, and checks that the product meets the specification. So no matter how many thousands of tests you have written, if they are all written by programmers, you will always have bugs. So QA, admins and everyone else, you can sleep well, because you need DevOps, while in it you are expected to do exactly what you are so good and unique in.


In the meantime, DevOps has not infiltrated all the teams in the world, we recommend visiting the conference Heisenbag 2016 Moscow , where we will discuss all sorts of testing problems, not only for testers. It will be interesting to both developers and technicals:

List of reports:

Source: https://habr.com/ru/post/314644/

More articles:


All Articles