March 19, 2019 at 12:26How Kiwi.com tests 1000 Python projects
Original english version of this article is here .
This is the title of a Alex Viscreanu talk in Moscow Python Conf ++. Two more weeks before the performance, but I, of course, already asked Alex about everything and under the cat I will share spoilers and backstage for preparing the report: what kind of open-source Zoo is what it does with our Python code and how it differs from mypy comrades.
- Tell me a little about Kiwi, what do you do in the company?
Kiwi.com is an online travel agency with secret sauce. The company was founded in the Czech Republic in 2012 under the name Skypicker, and in 2016 the service changed its name and moved to Kiwi.com. Kiwi.com is now in the top five largest airline ticket aggregators in Europe.
A cool feature of Kiwi.com for users is that we find connecting options for airline flights that usually do not work together, and we take care of all kinds of connecting problems.
As for me, I'm a full-stack developer, moved from Spain to the Czech Republic to work at Kiwi.com. I worked with Python on the backend, JavaScript and the zoo of different kinds on the frontend: Backbone.js, Angular, Vue.js.
At Kiwi.com, I joined the infrastructure team, so I mainly develop and maintain internal tools for developers. This work requires in-depth knowledge about infrastructure management and deployment tools, I think we can say that I'm actually doing DevOps, with a slight bias in the Dev part .
- How many Python developers are there in Kiwi? What projects are you using Python for?
We have more than 350 developers , 200 of them use Python every day. At Kiwi.commicroservice architecture , and each team is responsible for several services. I don’t think that it can be said that one of them is the most important, or that all developers are working on one thing. Moreover, the backend has closed code, and I cannot talk too much about it.
But we have some interesting open source projects available on GitHub:
- What about CI / CD and deployment infrastructure?
We use GitLab as a source code repository, and, of course, GitLab CI integrates best with it . This is a pretty good solution, it is flexible and allows you to build productive pipelines. And using a bunch of GitLab CI and our Crane tool, we can deploy projects in different environments at the click of a button (or fully automatically if you have the guts).
We provide all CI with a fleet of EC2 autoscale instances. Due to this, you can easily add power as needed, and save without holding unused servers during off hours.
We orchestrate the infrastructure with Rancher, which has proven itself perfectly in our workload and in our conditions.
- It seems you prefer Python. Do you use any other languages, and for what?
The second most used language is JavaScript , mainly for the frontend and GraphQL API. In addition, there are Kotlin and Java for Android applications; Swift and Objective-C for iOS; GoLang is used in some places for a bunch of services, and C / C ++ for the flight search engine.
- You mentioned the open source project The Zoo. Why are Kiwi open source projects? What is your benefit?
Like many other companies, we use open source in almost everything that we develop. It may sound like a cliché, but when you get so much, it would be nice to give something in return. This is a contribution to collective knowledge.which helps us all move forward.
Besides the fact that we will benefit from what we post in open source, it is also useful for us. Other people can look at the product from a completely different angle and offer something that we did not think or suspect.
- Tell us a little more about The Zoo. How many repositories do you check with it?
We have approximately 1,300 repositories in internal GitLab and about 100 in public GitHub. Total close to 1500 .
We scan each of our repositories, even if the service is not registered with The Zoo. The idea is that, firstly, the more analytics, the more accurate the conclusions, and secondly, when in the future the service connects to The Zoo, we will already have data on past behavior.
- An impressive number! And how many mistakes do you usually find? Do you remember some special catch?
Now in our database there are approximately 26,000 problems found , that is, about 20 problems per project. True, most of them are not "problems-problems", but simply recommendations.
Usually a new check appears in The Zoo after some problem has been discovered in one of the repositories. If it seems to us that this can also appear in other places, we start a new check in The Zoo. Just to make it easy to determine which projects are affected, and make sure that we can fix the error everywhere as soon as possible.
You should not expect The Zoo to find critical security breaches or complex code problems. We have other tools for them, and even if we implement them in the platform, it is worth detecting critical bugs even before The Zoo. Rather, it is needed so that a single guideline is respected in all repositories.
- That is, The Zoo as such does not have any default checks? Do you need it so that it is convenient for the developer to write any checks that he wants? You have made The Zoo and are testing a lot of everything with it. Can you give some examples?
True, The Zoo is a platform in which everyone can write their own test. Our checks are suitable for our rather specific configuration, but we want to open them as well.
As I said, the checks are based on the problems found in our services. They range from README recommendations to more complex configuration checks, such as nginx.
- Sounds like a “must have” for any large company! Will you tell about this in more detail in your report on Moscow Python Conf ++?
I think it will be more interesting how to make it easy and quick to run tests across all repositories. But, of course, I will tell you about what we check at Kiwi.com. I hope this will be useful for conference guests.
I urge everyone to try The Zoo, play with it, write their own checks and thus expand the general knowledge base. I am sure that in it you can find something suitable for you.
- Thanks! Finally, if you could go back 5 years, what advice on Python would you give yourself?
It’s not easy ... I started writing in Python 3 only a year and a half ago, but for myself in the past I would highly recommend starting as early as possible. Python 3 is the natural evolution of a language, she defines the basics. Now I would never return to Python 2. The point is not only that the end of its support is close, but for the most part that I'm already used to the features of the new version.
Back in time travel, I would grab the baggage of some good libraries that I met during that time, and some good practices that I'm still learning.
This is the title of a Alex Viscreanu talk in Moscow Python Conf ++. Two more weeks before the performance, but I, of course, already asked Alex about everything and under the cat I will share spoilers and backstage for preparing the report: what kind of open-source Zoo is what it does with our Python code and how it differs from mypy comrades.
- Tell me a little about Kiwi, what do you do in the company?
Kiwi.com is an online travel agency with secret sauce. The company was founded in the Czech Republic in 2012 under the name Skypicker, and in 2016 the service changed its name and moved to Kiwi.com. Kiwi.com is now in the top five largest airline ticket aggregators in Europe.
A cool feature of Kiwi.com for users is that we find connecting options for airline flights that usually do not work together, and we take care of all kinds of connecting problems.
To rate our scale, here are the numbers on Kiwi.com: 90,000,000+ daily searches, 25,000 daily sales seats, and more than 15,000,000 available flight combinations.
As for me, I'm a full-stack developer, moved from Spain to the Czech Republic to work at Kiwi.com. I worked with Python on the backend, JavaScript and the zoo of different kinds on the frontend: Backbone.js, Angular, Vue.js.
At Kiwi.com, I joined the infrastructure team, so I mainly develop and maintain internal tools for developers. This work requires in-depth knowledge about infrastructure management and deployment tools, I think we can say that I'm actually doing DevOps, with a slight bias in the Dev part .
- How many Python developers are there in Kiwi? What projects are you using Python for?
We have more than 350 developers , 200 of them use Python every day. At Kiwi.commicroservice architecture , and each team is responsible for several services. I don’t think that it can be said that one of them is the most important, or that all developers are working on one thing. Moreover, the backend has closed code, and I cannot talk too much about it.
But we have some interesting open source projects available on GitHub:
- Phoenix - a tool for notifications in Slack about incidents;
- Crane - a script for deployment to Rancher directly from GitLab;
- The Zoo is a set of smaller services that can nevertheless be very useful.
- What about CI / CD and deployment infrastructure?
We use GitLab as a source code repository, and, of course, GitLab CI integrates best with it . This is a pretty good solution, it is flexible and allows you to build productive pipelines. And using a bunch of GitLab CI and our Crane tool, we can deploy projects in different environments at the click of a button (or fully automatically if you have the guts).
We provide all CI with a fleet of EC2 autoscale instances. Due to this, you can easily add power as needed, and save without holding unused servers during off hours.
We orchestrate the infrastructure with Rancher, which has proven itself perfectly in our workload and in our conditions.
- It seems you prefer Python. Do you use any other languages, and for what?
The second most used language is JavaScript , mainly for the frontend and GraphQL API. In addition, there are Kotlin and Java for Android applications; Swift and Objective-C for iOS; GoLang is used in some places for a bunch of services, and C / C ++ for the flight search engine.
- You mentioned the open source project The Zoo. Why are Kiwi open source projects? What is your benefit?
Like many other companies, we use open source in almost everything that we develop. It may sound like a cliché, but when you get so much, it would be nice to give something in return. This is a contribution to collective knowledge.which helps us all move forward.
Besides the fact that we will benefit from what we post in open source, it is also useful for us. Other people can look at the product from a completely different angle and offer something that we did not think or suspect.
- Tell us a little more about The Zoo. How many repositories do you check with it?
We have approximately 1,300 repositories in internal GitLab and about 100 in public GitHub. Total close to 1500 .
We scan each of our repositories, even if the service is not registered with The Zoo. The idea is that, firstly, the more analytics, the more accurate the conclusions, and secondly, when in the future the service connects to The Zoo, we will already have data on past behavior.
- An impressive number! And how many mistakes do you usually find? Do you remember some special catch?
Now in our database there are approximately 26,000 problems found , that is, about 20 problems per project. True, most of them are not "problems-problems", but simply recommendations.
It's great when you can automatically catch significant errors.
Usually a new check appears in The Zoo after some problem has been discovered in one of the repositories. If it seems to us that this can also appear in other places, we start a new check in The Zoo. Just to make it easy to determine which projects are affected, and make sure that we can fix the error everywhere as soon as possible.
You should not expect The Zoo to find critical security breaches or complex code problems. We have other tools for them, and even if we implement them in the platform, it is worth detecting critical bugs even before The Zoo. Rather, it is needed so that a single guideline is respected in all repositories.
- That is, The Zoo as such does not have any default checks? Do you need it so that it is convenient for the developer to write any checks that he wants? You have made The Zoo and are testing a lot of everything with it. Can you give some examples?
True, The Zoo is a platform in which everyone can write their own test. Our checks are suitable for our rather specific configuration, but we want to open them as well.
As I said, the checks are based on the problems found in our services. They range from README recommendations to more complex configuration checks, such as nginx.
- Sounds like a “must have” for any large company! Will you tell about this in more detail in your report on Moscow Python Conf ++?
I think it will be more interesting how to make it easy and quick to run tests across all repositories. But, of course, I will tell you about what we check at Kiwi.com. I hope this will be useful for conference guests.
I urge everyone to try The Zoo, play with it, write their own checks and thus expand the general knowledge base. I am sure that in it you can find something suitable for you.
- Thanks! Finally, if you could go back 5 years, what advice on Python would you give yourself?
It’s not easy ... I started writing in Python 3 only a year and a half ago, but for myself in the past I would highly recommend starting as early as possible. Python 3 is the natural evolution of a language, she defines the basics. Now I would never return to Python 2. The point is not only that the end of its support is close, but for the most part that I'm already used to the features of the new version.
Back in time travel, I would grab the baggage of some good libraries that I met during that time, and some good practices that I'm still learning.
Come April 5 to Moscow Python Conf ++ to find out the details of working with this interesting open source project and, perhaps, to borrow Kiwi experience in something.