Hello, today I would like to tell you about environments, in particular test environments, what they are all about, why a tester needs to know about them, what a tester does in each of these environments, and so on. This video will be one of the first on the channel related to the CI/CD process. I plan to record a separate video about the CI/CD process. In a nutshell, I’ll tell you that this is continuous integration and continuous delivery, which allow us to make our constant changes to the code and deliver part at any time our work product to the end user, or there to our customer. And just part of this CI/CD process is understanding the concept of environments that can exist. What is the environment? An environment is, essentially, a set of software and hardware that allows us to run our application and deploy it somewhere. What does deployment mean? This is the following definition, either deployment or deployment. This is, in essence, deploying our code, running it, again, somewhere in a separate environment, for example, on a server, remote or local. A local server can be your computer, for example, a remote one, of course, some cloud solutions, for example, or just some kind of physical server where you can deploy your application somewhere and work with it. Let's talk a little about each of these environments, and I will tell you what exactly a tester can do in them, and why they even exist. So, the first environment is a local environment, as the name suggests, it is deployed somewhere locally, that is, on your computer, for example. And usually developers work in this environment and conduct unit testing or component testing of individual methods, individual functions of our application, even specific code, I would say. And sometimes testers can also deploy something locally if there is such a process within the company, and part of this process is testing the functionality specifically on your computer. without connecting to the Internet there, then you can also do this locally. Most often, for local deployment of your application, in order for it to run, Docker is used there, for example, a special tool. I don’t have a video about it on my channel, but you can basically find articles or basic courses related to it on the Internet without any problems. And you shouldn’t go any further, because in fact a tester, especially a manual one, doesn’t need to be very immersed in this process. When you come to a company, there are instructions or procedures related to how you can locally deploy this environment and work with it. If there are no procedures and instructions, then ask questions, they will tell you about it without any problems. Usually these are just a few commands that allow you to first go to, for example, your remote GitHub repository. As a reminder, this is where your code is stored. Take exactly the code that you need, clone it onto your computer, essentially copy it. Launch Docker, enter a few commands, and your application will be deployed and you can work with it. It sounds simple, but sometimes there are difficulties, but this is usually talked about either on the projects themselves, or on the Internet, like an ordinary normal engineer, you can find information on how to solve them. Therefore, I would strongly advise you not to go into details, especially if you are a novice specialist. Okay, the local environment is clear, to go to it, you just enter in the address bar, when you expanded it, localhost, or One Hundred Twenty Seven Zero Zero One, depending on the operating system, it can sometimes differ if some port is busy, too It may differ a little, but in general it works like this. When you enter this into the address bar, conditionally, if you have a frontend, a regular page of your resource is displayed, which you can work with as your final application. Plus, if there is a back-nd, you can also conduct some kind of back-nd interactions. For example, front-nd is what you see on the client in your browser. It is a graphical representation, a graphical interface, that you can interact with when you open any page on the Internet. Back-nd is the business logic of your application. In particular, these could be some kind of API integration interactions that happen under the hood. Or there is a connection with the database, working with the database, and so on. You can’t see this with your eyes, but if you are a normal tester and know how to at least do gray box testing, then you will also figure out how to work with it without any problems. OK. Next we have the following environment - this is the Dev environment. This is essentially a sandbox for developers, sandbox. I think those who play games know what a sandbox is. It's basically a place where you can do whatever you want with your application, and it's essentially where some working functionality is already tested by the same developers before they commit it to testing, for example. Also, if the company does not have enough budget, then you can have testers work on the DEV circle and test it, because after all, the DEV circle very often happens that this is already a remote environment on a remote server, and we can already say what you are testing is not isolated locally, but somewhere already in a more or less real environment. And here, for good reason, I wrote a number of tools that allow you to perform this deployment, in particular Jenkins, but you also need GIT, where it is stored your application code, you need a connection to the database, to the server of this database, and Jenkins allows you to simply automate this deployment process so that you don’t do it all by hand, but simply enter the necessary parameters, the necessary data, where you need to get it from access to the DB, where you need to get the code, and just click on the run build button, and you have a build, this is an intermediate version of your product, deployed specifically in the environment that you need. Perhaps, if I have enough energy and time, I will record a separate video about setting up some kind of basic pipeline, not even a pipeline, but just a process, how it can be done in a gentleman’s practice, so that you can see and understand it with your own eyes, but perhaps I can’t promise . I have a separate course about Git, you can watch it, about databases there is also a separate course on the channel, you can watch how to work with them, but I’ll add something else about CSED later. And, in principle, a tester needs to be able to work with these tools. With Jenkins there is nothing complicated, because in practice you just come to a project where everything is already configured, where all the parameters are there, or parameters that just need to be changed, but they are already indicated there somehow, you just wrote, for example, the server, database you need to connect to, or specifically the repository from which you want to get your code. and click on the Run button, that’s it, that is, there’s nothing complicated there, just monitor how your deployment is going on, assembling your build so that there are no problems, read the logs, know what’s broken there, there’s usually nothing complicated there either no, if everything is properly documented, plus make sure that your Jenkins, not Jenkins, but the server, does not get clogged, and you need to periodically update builds, and all sorts of things like that, if this is simple automation, and you are a manual tester , not an automator, just follow the progress of how builds are assembled there, tests are assembled and tests are carried out, this is also, in fact, you just monitor the statuses and so on. In general, maybe I’ll write something about Jenkins later. Okay, the Dev environment is clear, you can connect to it as if you were a regular resource, just adding def to the prefix, that is, a domain, and an additional domain to the name, and then you will see the same thing, it will just work somewhere on the network Internet. But as a tester, we are, of course, interested in working with the QA environment, that is, this is the environment where we conduct the main testing. That is, in fact, a build comes to us, already when the developers are confident that we can transfer the task for testing, they believe that there are no bugs there, the testers take it to work and deploy it in their own special environment, on a special stand QA. It's called a QA environment, where the code is working and can be tested. We immediately conduct smoke, yes, remember, smoke testing, certify our build, and say that’s it, we can continue to work with it. Next we have the critical pass, that is, these are the functionality that the user uses every day we test. Some positive tests, negative tests, depending on whether you have enough time for them, but you definitely need to do a couple. In principle, this is the most basic thing that is carried out there. Of course, you can delve into functional and non-functional types of testing, but I don’t see much point. That is, we, in essence, test the functionality that came to us and conduct functional testing. Okay, this takes place at the QA stand, depending on whether you need several stands, or if you do not need several stands, they will create them for you. That is, for example, if you have several testers, you often have many tasks that need to be tested, and one stand is occupied periodically, then they will create a second one for you, if, of course, the company has enough money. How can this be optimized? You can, for example, not test isolated functions. By the way, you shouldn’t test isolated functions in terms of functionality, but still test them together so that they show some kind of integration interactions, and we also look at the integration level to see how it works. But in general, yes, this approach is better when you have a lot of functionality, that is, we are waiting for some critical piece of functionality to accumulate, or you have a calendar, that on Monday, Wednesday, Friday, for example, we do deployment, test our applications and collect some kind of pool of tasks that we can do. so that these stands are used competently, rationally and do not just stand idle, or, on the contrary, do not just occupy someone’s time. How does communication occur when working with QAs? A separate chat for testers is created, and the tester simply writes that the QAs stand is busy, the QAs stand is free. When someone else sees there, he can go and work with it, because we don't need another tester during your testing to start a new deployment process and overwrite all the data, which you already have there, and the results of your testing. Therefore, here it is necessary to organize proper communication within the company, and that is why sometimes these case-ends are shared. We also follow the same link, enter it, our application opens and we work with it, testing the front-end, back-end, depending on what we need. If there is a database specifically for this environment, then we connect the database and work with it. That is, here is how your process is organized; this, I think, will be more clear to you within the company. The main thing is that you now understand the general concept of these environments. By the way, environment, or stand is also called, it’s all the same. If you hear, then this is what we are talking about. Plus you also have your own test environment, these are the test tools that you use for testing. This is also part of the environment, just a little different. Okay, let’s imagine that we have tested, everything works well and we can transfer our application to the next stage, to a pre-release state, to a stage, to a stable version, to a stable build of some kind. to a stable environment. And here regression testing is usually carried out, that is, we are convinced that everything works well. If it still didn’t work well, then it’s usually our flow, we create bug reports, or if you don’t have a procedure when you work in QA, create bug reports, which means comments on bugs, not on bugs, but You leave it to functionality, to user stories, or you find out all this in private messages, or in general chats, in general, here’s how everything is arranged for you. and then it is also corrected and transferred to QA. Okay, back to the stage, I got carried away again. That is, here we checked that everything is working well, all critical bugs have been fixed, which means we must conduct regression testing, remember what this is, yes, this testing is related to changes, that is, conditionally, when we introduce some new code, whether it's fixing a defect or new functionality, our code changes, we must make sure that it does not affect, and this change does not affect to all the rest of the code and to some functions that relate to this module where changes were made. Therefore, conduct regression testing usually just before the release, a few days in advance. And that’s exactly what we do at Stage. We carry out regression testing, if everything works well, then we give the OK, and then we select, for example, we go to Production, and this application can be used by our end users, and we can release. Sometimes this regression testing is also carried out at a QA stand, that is, it’s already set up here, but, of course, it’s better if you have a separate stand for this. And it’s not for nothing that it’s called “prerelease”, also, maybe you call it “prerelease environment”, because it repeats as much as possible what is happening in your production, so that you can make sure that everything is okay if you all If you're playing for production, you won't have any problems. Also, since this is a stable build, a stable environment, we cannot make any code changes here, except for fixing some critical bugs, that is, a phase called code freeze begins, and, for example, developers do not can write, or rather, merge new changes, merge them, if we speak the language of GIT and working with branches, they can only work on their own branches, but not on the branch where you have the application that you want in the future release. Very often, by the way, the name of all these stands is related to the names of the separate branch on which we work. That is, developers can write code that is no longer associated with this iteration specifically, with this increment that we want to deliver to the end user, but the developer cannot make new changes here, except for some bugs. That is, conditionally, we carry out regression on the stage, find critical bugs, which means we create a bug, this is all fixed and, again, it can come to QA and get to the stage, or it immediately gets to the stage, depending on whether you have you have the time or not. Again, this is all discussed within your company. Okay, the regression is clear, we go to stage.test.com, we also work and test. Okay, there are also UATs. UAT does not exist everywhere, as a separate environment, it can be either before production or somewhere separate from production, that is, it is not part of this chain, that is, it can simply be somewhere behind UAT does not affect a specific Prod there, but simply, more precisely, behind Prod and does not affect it. Conventionally, some acceptance testing can be carried out there separately group of users. For example, you are developing software for lawyers, and there is some working group of lawyers who can test it and say, yes, okay, that’s it, we have closed all the acceptance criteria there, and the application works as we expect, we can do it there release, or it’s just being tested separately somewhere else. Also, UAT, for example, is beta testing, when you have some kind of game, for example, and before release it is given to a limited number of users, there are several thousand, for example, they test and say that yes, everything is ok, if everything is good, then we are preparing our application for production, specifically the game. Okay, UAT may or may not exist. Production is the most important environment where our end user specifically works, that is, where we run the application in-life, so to speak. That is, here we must be sure on One Hundred that everything works well, all critical bugs were fixed at previous stages, in previous environments, and it already works here our user. As for the specifics of testing in production, here we do not carry out all testing, this is stupid, and this is bad practice, if you repeat the entire testing process, then something is wrong with you, that is, conditionally, your production can be as excellent as possible from the stage, it shouldn’t be like this, you shouldn’t be there, for example, to make sure that everything seems to work, but this is a very bad practice. In a nutshell, this is some kind of minimal smoke, check that all the main functionality of the application is working and selectively check those functionality that are new to your application. Because it makes no sense and is generally dangerous to carry out testing manipulations in production. In principle, this would be bad practice, but for some reason many companies still believe that on Production we should carry out the entire testing cycle and work with it. Okay, so these are the environments we have, this is a concept you need to know, why it is important, because when you come to work, you will most likely encounter these environments, and, most likely, you will need to understand that happens at each of them. If you suddenly build processes from scratch, you will also need to tell your manager and team specifically. what works in these environments, why you need, for example, separate environments and a budget for this environment, so also remember that you don’t come to the first meeting with your eyes wide open, as I did, where they didn’t tell me about these environments, when I arrived and there we have a stable build, stage, frieze code, yes, there is QA, you work on it, in this environment there is DeV, there is a local environment. So that you too do not get lost, I hope that I have told you in detail about what can happen here, how it physically works, practically works. I can’t show it in the current conditions, but I’ll try to record some kind of separate video, a little about self-deployment, probably how to configure it minimally. and see how it works, and about the CI/CD process itself, where exactly, where I will tell you specifically where this deployment is located in the process itself, in this pipeline, the conveyor of our CI/CD. I hope that this video was useful to you, if so, be sure to write about it in the comments, ask all the questions that you have as part of this video and write in general, are you interested in the topic of Ci/CD, should I record a video about it, perhaps? even pack it into some kind of small mini-urse here on the channel for free, which anyone can watch there. And if you didn’t understand everything I said, of course, subscribe to this channel too and start watching the video from the very first, because you need to form a general picture and understanding of the fundamental principles of testing and, in general, the work of some of the tools and concepts that are here. And the channel has comprehensive videos on this topic, at least for beginners. So I will be happy to see you among my subscribers. See you on this channel very soon in new videos.