Testing sites using builds: what it is and how it works
Testing on the combat site is prohibited.
If you are creating websites, you probably understand why this is so. And most likely you are familiar with the problem, which will be discussed.
')
Imagine that you made the site and already launched it into combat operation: cleaned all the dirt from the tables, checked everything and put it in order so that customers could see the finished working system, and not incomprehensible “under construction” filled with features than.
And suddenly out of nowhere in your candy some Vasya Pupkin, Bill Gates, Vladimir Putin, or even incomprehensible words in the form of a set of letters begin to appear. And even worse, when these incomprehensible people begin to bill millions of rubles, which are automatically transferred to your company's 1C-ku.
It turns out that one of the employees took the initiative and decided to “check” how the site works. Of course. After all, except for him, no one can do it just as well. Only he is capable of it.
We will not argue here about whether such employees can be tested in principle, without knowing the functionality of the site and the process as a whole.
Just to avoid such situations, you need to impose a total ban on testing on combat systems - bring it to all employees and burn out these words on their foreheads with a hot iron.
But how then to test, the question arises?
But for this you can use the so-called. assembly.
Assemblies are complete copies of the combat site, where you can and should be tested.
It is important that this be exactly an exact copy of the combat. As experience shows, no artificial configuration shows the errors that occur in the combat system. Only on an exact copy of the combat site can you understand and understand the problems sent by users.
What is the best way to organize an assembly system and how to do it?
The configuration has proven itself well, when several assemblies are done at once.
Those. N separate sites are created - copies of the combat system: build1.site.ru, build2.site.ru, ..., buildN.site.ru
In this case, one of the assemblies (for example, 1st) is special - no changes should be rolled onto it. The rest are designed to debug on them new tasks, coded by programmers.
Special 1st build is needed only to always have on hand an exact copy of the combat site completely without any changes. For what?
And where and how will you check the error messages sent by users?
Sometimes in those support letters come from users in which they describe a serious error found on the site. How will you check this error if it is required to perform actions with the user's cash balance? Not in the battle to do it, right?
For such tasks, an exact copy of the combat site, but working completely separately from it, and using special test services, is very well suited.
On this test copy, nothing should be pumped from above. It must be exactly a complete and exact copy of the combat system. Only then will the test be accurate.
The 1st assembly can be made automatic, i.e. so that it itself is updated daily (a fresh database dump and all scripts are uploaded). Well, add the ability to update right now so that you can see the actual data at the moment.
The rest of the assembly does not necessarily build on a daily basis. It is enough to build them “on demand” - i.e. only when the programmer or the tester needs it (though for this you need to work hard on the speed of deployment of the assembly).
And do not forget to introduce such a thing as blocking.
When assemblies are used by several programmers at once, situations are inevitable when one programmer rolls his changes onto an assembly used by another programmer.
To prevent this, make it possible to lock the assembly. If an assembly is locked, then it cannot be rebuilt until the lock is unlocked.
The implementation of the assembly is quite simple from a technical point of view. They are easily done using standard shell scripts + creating a single web page that runs the shell script to deploy the assembly in nohup mode.
The deployment procedure is also not difficult. Everything is done in three steps:
Of course, you don't have to do everything on the shell. You can use any tool. If there is a ready-made tool for assemblies, then why not use them?
By the way, notice that when you create an assembly, no manual changes are made! This is done specifically to avoid errors caused by human factors. It helps, by the way.
It is worth noting that programmers should not use assemblies for encoding. It's just that it will slow down development a lot.
Correctly use the assembly as a tool for the final testing of the task.
Every programmer on a computer is best to have his own copy of the site and encode it in it. And only then, when the task is ready, check it on the assembly.
Since assemblies are assembled (deployed) automatically, the manual influence on them is minimized.
You can not do anything with your hands at all. Do not change the script or fix the database, nothing at all.
This is very well reflected not only in the number of errors, but also in the deployment of the combat site (it is also assembled automatically, without human intervention), because all the procedures have already been debugged and tested earlier on the assemblies (but still have to have the procedure for rolling back to the previous state - not prevent).
Using assemblies for testing sites has proved its effectiveness in practice, so if you are developing a site, do not forget to create an assembly system for it.
If you are creating websites, you probably understand why this is so. And most likely you are familiar with the problem, which will be discussed.
What are the assemblies for?
')
Imagine that you made the site and already launched it into combat operation: cleaned all the dirt from the tables, checked everything and put it in order so that customers could see the finished working system, and not incomprehensible “under construction” filled with features than.
And suddenly out of nowhere in your candy some Vasya Pupkin, Bill Gates, Vladimir Putin, or even incomprehensible words in the form of a set of letters begin to appear. And even worse, when these incomprehensible people begin to bill millions of rubles, which are automatically transferred to your company's 1C-ku.
It turns out that one of the employees took the initiative and decided to “check” how the site works. Of course. After all, except for him, no one can do it just as well. Only he is capable of it.
We will not argue here about whether such employees can be tested in principle, without knowing the functionality of the site and the process as a whole.
Just to avoid such situations, you need to impose a total ban on testing on combat systems - bring it to all employees and burn out these words on their foreheads with a hot iron.
But how then to test, the question arises?
But for this you can use the so-called. assembly.
Assemblies are complete copies of the combat site, where you can and should be tested.
It is important that this be exactly an exact copy of the combat. As experience shows, no artificial configuration shows the errors that occur in the combat system. Only on an exact copy of the combat site can you understand and understand the problems sent by users.
What is the overall build system
What is the best way to organize an assembly system and how to do it?
The configuration has proven itself well, when several assemblies are done at once.
Those. N separate sites are created - copies of the combat system: build1.site.ru, build2.site.ru, ..., buildN.site.ru
In this case, one of the assemblies (for example, 1st) is special - no changes should be rolled onto it. The rest are designed to debug on them new tasks, coded by programmers.
Special 1st build is needed only to always have on hand an exact copy of the combat site completely without any changes. For what?
And where and how will you check the error messages sent by users?
Sometimes in those support letters come from users in which they describe a serious error found on the site. How will you check this error if it is required to perform actions with the user's cash balance? Not in the battle to do it, right?
For such tasks, an exact copy of the combat site, but working completely separately from it, and using special test services, is very well suited.
On this test copy, nothing should be pumped from above. It must be exactly a complete and exact copy of the combat system. Only then will the test be accurate.
The 1st assembly can be made automatic, i.e. so that it itself is updated daily (a fresh database dump and all scripts are uploaded). Well, add the ability to update right now so that you can see the actual data at the moment.
The rest of the assembly does not necessarily build on a daily basis. It is enough to build them “on demand” - i.e. only when the programmer or the tester needs it (though for this you need to work hard on the speed of deployment of the assembly).
And do not forget to introduce such a thing as blocking.
When assemblies are used by several programmers at once, situations are inevitable when one programmer rolls his changes onto an assembly used by another programmer.
To prevent this, make it possible to lock the assembly. If an assembly is locked, then it cannot be rebuilt until the lock is unlocked.
How builds are arranged technically
The implementation of the assembly is quite simple from a technical point of view. They are easily done using standard shell scripts + creating a single web page that runs the shell script to deploy the assembly in nohup mode.
The deployment procedure is also not difficult. Everything is done in three steps:
- rolls fresh database dump
- the necessary branch from svn is rolled on scripts
- a script is launched that makes changes to the database (taken from the same svn branch)
Of course, you don't have to do everything on the shell. You can use any tool. If there is a ready-made tool for assemblies, then why not use them?
By the way, notice that when you create an assembly, no manual changes are made! This is done specifically to avoid errors caused by human factors. It helps, by the way.
It is worth noting that programmers should not use assemblies for encoding. It's just that it will slow down development a lot.
Correctly use the assembly as a tool for the final testing of the task.
Every programmer on a computer is best to have his own copy of the site and encode it in it. And only then, when the task is ready, check it on the assembly.
What other benefits do they give?
Since assemblies are assembled (deployed) automatically, the manual influence on them is minimized.
You can not do anything with your hands at all. Do not change the script or fix the database, nothing at all.
This is very well reflected not only in the number of errors, but also in the deployment of the combat site (it is also assembled automatically, without human intervention), because all the procedures have already been debugged and tested earlier on the assemblies (but still have to have the procedure for rolling back to the previous state - not prevent).
Results
Using assemblies for testing sites has proved its effectiveness in practice, so if you are developing a site, do not forget to create an assembly system for it.
Source: https://habr.com/ru/post/267135/
All Articles