Many companies publish their code in open-source. We are also no exception. Avito engineers are actively publishing their work on GitHub . But the code is not the only thing the company can share with the community. Of no less interest is the description of various processes, guidelines and best practices. Today we are taking the first step in this direction and posting on GitHub the first version of Avito Playbook . What is it and why is it necessary - I tell under the cut.

What is a playbook

Initially, the term playbook came to us from American football. This is something like a set of rules by which the team plays, and the best practices recognized by them, the adopted strategy and tactics. For the company, he plays the same role - this is a set of standards that the team develops over the course of its life. These can be values, rules of employment, practice code review, and even a list of favorite bars that the team goes to on Fridays. The playbook contains all the information with which you introduce the beginner in the first weeks of his work.

Strictly speaking, you probably already have a playbook. This may be a pack of guglodkov, a section in Confluence, a repository in VCS. The main thing is to adhere to two basic rules: information must be relevant and structured.

Avito Playbook - first version

For 10 years, we have developed, well, a lot of interesting materials that I want to share. But before transferring them to open-source, you need to do a lot of work. Old information to update, missing to collect, wipe secret data and hide under the fingerboard. The process can be delayed for long months. But in full accordance with the Agile-manifest, we decided to work iteratively and gradually share new information.

In the first version we talk about:

• Avito in numbers - how many employees, developers, RPS and servers we have;
• mission and values ​​- where and how we go;
• organizational structure - units, clusters and working schedule;
• business processes - OKR, performance review;
• technological processes and practices - releases, developer experience framework, technical radar, open-source;
• working conditions - training, training, conferences and other buns.

The plans - to dig into all this is much stronger. For example, we very much want to share our release policies for the site and mobile apps and automated testing practices. Another option is to describe in detail the interview process, its structure and topics raised.

We are looking forward to your feedback. If you want to learn more about some aspect of the company, the process device or something else, then feel free to get an issue on GitHub . They can also be used to ask a question to our engineers in different directions - we will try not to leave anything unanswered.