Vivaldi development: work on bugs

Hello! Software development is today itself a difficult task due to the abundance of various programming languages, operating systems, platforms, devices and other factors. But, perhaps, the creation of a browser is one of the most difficult tasks requiring special attention: after all, the browser is today the main application that every Internet user works with every day. And considering that the content today is presented in such a complex dynamic form, as the developers of the first browsers never dreamed of, the principles of working with this content have evolved from “to see - read” into full-fledged work with applications, the task is not trivial at all. In general, the conclusion suggests one thing: browsers are becoming increasingly difficult today and, as a result, more and more errors penetrate the code during the development process. How can you deal with this? How are we fighting this at Vivaldi? Here we will talk about this briefly.

So, I'll start with the main thing. What is the development process? It consists of several important steps, including the actual writing of the code, testing, and the release of the public version. So it works, for example, if you are writing a program of the level “Hello, world!”. However, in fact, when developing a browser, it works in the same way, just at a slightly more complicated level, including several releases of different degrees of readiness and several “filters” of catching errors. in our company the process is as follows.

First stage

At the first stage, developers add their own code to the browser, while on the company's servers, the browser source code is compiled daily into binary packages, several versions a day. These are internal assemblies in which developers have the opportunity to check their recent changes, as they say, in action - on a live browser.
')
Also at this stage, the primary error trapping takes place - here the developers check the performance of their code, whether everything works in it as it was intended. In addition, these assemblies contain all the experimental functions that go through the process of creating and debugging - in the most raw and unusable form. In this regard, these internal assemblies never leave the company’s borders (with rare exceptions, when a leak occurs due to an oversight - such as, for example, it happened just yesterday :-)).

Separate “lucky ones” could understand this by discovering a green browser icon after the update (see on the left) - it is used for internal test builds. However, there is a green icon in the assembly of the next stage.

Second phase

At this stage, an assembly is produced for Sopranos - our voluntary testers from around the world (including Russia), who provide us with invaluable and unique assistance in creating a browser. Their build, released daily, also has a green icon and all the experimental features, but the most obvious errors in the fresh code of the developers are already caught there. At this stage, testers (and all of them are excellent specialists in programming and debugging) check how the newly added code affected the already existing functions. This is a very important stage, allowing to identify the bulk of the really critical shortcomings. You can also add that it is Sopranos that first of all checks all the error messages that come to our BTS daily from users, and this is already

Third stage

These are our weekly public test builds that come out with a black (actually with a gray-blue ) icon (see right). These versions are collected for wide testing and they lack many experimental features that are not yet ready for such a massive use - we just drown in reports that something is not working. Well, the element of surprise, too, has not been canceled.

Weekly builds for us are no less important than the internal ones: it is here that most of the errors and shortcomings are caught due to the fact that the users of these versions have an extremely wide variation both in hardware and in personal habits in working with the browser. There is a full test drive browser in real combat conditions. Users find such flaws that are hidden from the eyes of both the developers themselves and the official Sopranos testers.

The main goal of releasing such test public assemblies is to grind and polish the browser code to prepare an already stable version of the browser, which comes out about once every 6 weeks and marks itself

Fourth stage

So - the final version. The familiar red icon and relatively stable, debugged code. Why - "comparatively"? Because the ideal is unattainable and completely get rid of all errors in the code today is almost impossible - software products have become too complex today. It's like with airplanes. Few people know that absolutely every aircraft carrying passengers from one geographical point to another at this moment has a log of currently known problems — a list of shortcomings with which the aircraft is allowed to work. In other words, absolutely intact aircraft are never in principle .

And with the browser - a similar story. It always contains a number of shortcomings that do not critically affect the operation of the application and allow you to fully use this version in daily work. Some of them are known to developers, some - not. And this is exactly the part that the users of the already stable version find over time - of which we are notified by sending error messages through the appropriate online form. These messages fall under the control of Sopranos, are checked, grouped and reported to developers with a proposal to correct right now or a little later - depending on the severity of the error or deficiency.

Most often, the shortcomings found at this stage are quite specific, rare, or unimportant, which leads to a rather long fix period, but if there are a lot of messages from users and the problem is clearly not of a single character, the developers increase the priority of this problem and move them to the queue closer corrections.

As a result

Of course, the whole process is described quite schematically and does not include many small, but important details, but in general it shows how everything works. What gives such a multi-level approach? It gives the uniformity of the development and debugging of the browser. All errors are filtered at each stage depending on the criticality, while this is done gradually, with the usual frequency. Thus, developers have approximately a constant amount of errors in the repair process and in the process of waiting a queue, testers (both official and unofficial - weekly assemblies) distribute among themselves the “responsibilities” of catching errors depending on their qualifications, and the end users of the browser get enough stable version that will work reliably in daily mode. Here, in brief, that's all. If you have questions - ask them in the comments, I will try to answer.

Also, do not forget to look at our official website vivaldi.com - there have been interesting changes lately and useful information appears, including an invitation to work .

PS Yes, if you suddenly forgot where you can download the browser Vivaldi - welcome !