Engineering blog: Automate Everything!

Person
Ivan Malykh April 16, 2021
Image

From an attic room idea to a serious organization

What is the easiest way to stay updated on what’s happening in engineering at Payt? In our opinion, technical blogs offer a great opportunity to communicate this with you. 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 give you a glimpse into Payt.

Image

When I started this article, I wrote an introduction for one of the tools used by our frontend team – Create React App. The aim 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 decided to adjust the purpose 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 bit of background about our software stack.

Payt offers the most comprehensive 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 testing. These tests can be performed 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 production 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 their 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. Their work may not be rolled out to the main branch until then.

Deployments

Developers wouldn’t be developers if they didn’t automate all their work. Thus, the deployment of developed functionalities at Payt is automated. Every new functionality – tested and approved – is automatically deployed to our servers.

To do

Despite the number of automated workflows, the Payt engineering team still faces many challenges. For example, we aim to spend less time on configuration, administration, and other repetitive and automatable tasks. Instead, we want to spend more time 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 provide us with a single blueprint of the software required to run our applications. It speeds up the deployment of new server instances and ensures consistency between different machines.

Image

By Ivan Malykh

Ivan is a developer at Payt. While his focus is mainly on the front-end, the back-end also captures his interest.

Share this article
Image
It seems like everyone is working on a separate project, but everyone operates like a cog in a machine – Jake Eggen, Developer
Image
If you are looking for a workplace with an excellent working environment, learning opportunities, and fantastic colleagues, then Payt Software is definitely worth considering – Ivan Malykh, Developer
Remove Cookie