What is the easiest way to stay informed about what’s happening in engineering at Payt? In our opinion, technical blogs offer a great opportunity to communicate this. My name is Ivan Malykh and I am a developer at Payt. To give you a bit more insight into our software, we try to write an engineering blog every month. I’ll give you a glimpse into Payt.
When I started this article, I wrote an introduction to one of the tools used by our frontend team – Create React App. The goal was to explain how this tool saved us a lot of time and effort in choosing, installing, and configuring various supporting third-party packages.
Along the way, I concluded that the first Payt software engineering article, instead of diving deep, could be a bit more general. So, I chose to adjust the goal of this article slightly. Today, we will discuss various measures in our workflow that increase the productivity of the engineering team and ensure that we can fully focus on developing new functionalities.
But first, a little background on our software stack.
Payt offers the most complete software in the field of accounts receivable management. This software consists of several web-based applications. Mainly, these are the Accounts Receivable Management app and Accounts Receivable Portal app. These two applications are “fed” with data from one and the same backend application.
The backend application of Payt consists – at the time of writing – of the following technologies:
Frontend applications of the Payt applications use, among others, these technologies:
Backend and Frontends communicate with each other through REST and GraphQL APIs and are hosted on the Amazon AWS infrastructure.
Payt has been around for a little over eight years now. Over those years, the system has grown and expanded significantly with various processes, functionalities, and the business logic that comes with it. Maintaining such an amount of logic is not trivial, but certainly not impossible.
Testing, testing, and more testing.
It may sound obvious, but many companies do not use any form of testing in their software.
Developing new functionalities at Payt always goes hand in hand with performing tests. These tests can be conducted in various ways. At Payt, we have chosen to have our tests written and executed by developers. The so-called Test-Driven Development. When developing a functionality, the developer must write the so-called unit tests for it. These unit tests are part of the code. When another developer starts working on a new functionality and accidentally breaks the existing functionality, the test suite will warn about it.
Git, Github, and Reviews
Git is a version control tool. The most used functionality of Git at Payt is the so-called “branches.” A branch is a divergence from the existing product code for developing a new functionality in isolation from the working production code. When the functionality is completed and the tests are written, the developer can offer her/his work for review. Github – a platform for development collaboration via Git – provides the ability to create Pull Requests. A Pull Request is the difference between the main branch and the branch of the new functionality (“feature branch”). A requirement for merging a Pull Request with the main branch is that the automated checks pass and that one or two colleagues approve the code.
Automated checks
As I mentioned above, the tests are part of the code. When developing a feature, a developer can run tests to ensure that the code works. Our test suite consists of 11,051 tests at the time of writing. Some of these test the integration between different components and are therefore slow. It would be a waste of our time if we had to run all eleven thousand tests before developing a functionality.
Therefore, we have an external system that ensures that every Git commit on the main branch is fully tested. Such a system (Continuous Integration or CI for short) also ensures that the feature branches are tested before they are reviewed by other developers.
In addition to unit, acceptance, and integration tests, there are also several other checks that ensure the quality of the code is maintained. A few of these are:
- Check on the percentage of code covered by tests
We aim for 100% and are currently averaging slightly above 90%.
- Check on code style
The code style check ensures that the way the code is written is consistent. A clear and consistent code style makes it easier for new team members to familiarize themselves with the code. Existing team members can also dive into an unfamiliar part of the application more quickly.
- API compatibility check
The backend and frontends at Payt are independent code bases, each with its own Git repository. The frontend UI depends on the data provided by the backend via the API. The frontend also expects a certain data structure. This check ensures that the developer is aware of the so-called “breaking” changes in the API.
When one of the checks does not meet the quality requirements, the respective developer must correct the errors or shortcomings. Her or his work may not be rolled out to the main branch before that time.
Deployments
Developers wouldn’t be developers if they didn’t automate all their work. Thus, the deployment of developed functionalities at Payt is also automated. Every new functionality – tested and approved – is automatically rolled out to our servers.
To do
Despite the number of automated workflows, the engineering team at Payt still faces many challenges. For example, we need to spend less time on configuration, administration, and other repetitive and automatable tasks. And instead, spend more time on developing new functionalities and expanding existing functionalities of our applications.
For instance, we are currently working on automating the setup of the servers on which applications run. The intention is to have our infrastructure documented in code. This will soon provide us with a single blueprint of the software required to run our applications. This speeds up the deployment of new server instances and ensures consistency between different machines.
