Hands-on Experience: Creating a Development Platform

To begin with, here is a brief discussion of the technologies behind the platform. We have described many of them in detail in our previous articles:

• Standard logging libraries: featuring a typical set of functions that do not change from product to product, including composition of logs, requirements for capturing and tracing data, etc.
• Microservice templates: allowing teams to create new microservices within just a few minutes.
• Project templates in Azure DevOps: creating a holistic view of project management: both at the top level, where managers plan product development, and at the bottom level, where developers execute tasks and release products to the customer.
• Quality Gates: automatic quality checks that set thresholds for moving a product down the development pipeline.
• Feature Flags: featuring toggles in the code and providing the business with leverage to control product features.
• The C4 architectural notation: a convenient model for comprehensive description of software architectures.

At the time of the transition to a common platform, different teams used these technologies in different ways: some were already used to working with feature flags, some were looking closely at them, templates were just being created, etc. Over the past few months, one way or another, all of our teams have experienced these practices in real life scenarios. And here are the results we came up with.

Logging libraries

These libraries provide teams with the same understanding of logging requirements. They combine a certain set of functional characteristics that do not change from product to product, such as the composition of logs, data tracing tools and standards, etc.

The capabilities of the standard libraries have been appreciated by all teams, and they are now used in all new projects. If necessary, individual technical details are finalized on the fly. Most importantly, the products include all the logging tools we need right from the start, making it easier for teams to support and monitor in the future.

Microservice templates

The point here is that teams can create new microservices in just a couple of minutes, according to the same architecture standards.

These funds are also successfully used in all new products. Over the last quarter, three of our teams saved 60-80 hours in total at the start of projects.

Upon having some practice, it became clear that it is difficult to prepare such a template in advance. But after the launch, it is quite a lively idea to build a template and industrialize the creation of microservices. On top of that, we have found tremendous value not only in the templates as such, but also in the pre-prepared TFS pipelines. In the future, we plan to template other areas of work as well, such as the frontend and individual, repetitive code sections.

Project templates

Another technology that is designed to relieve teams of routine, and the company as a whole, to provide a one-for-all approach to project management.

These templates are successfully used by all teams. As a result, there is less TFS routine, the task hierarchy is the same for everyone, as well as the principle of branches naming. The next plan is to figure out the size of the tasks, so that tasks and PBI include approximately the same number of hours, but that’s just a small thing.

Quality Gates

We are talking about static code analysis, for which we use SonarQube. Now backend services in our new projects are tested everywhere, unit-test coverage is 80-100%.

Currently, there are 121 repositories under SonarQube verification, of which 81 are actively developing (there are commits from the last six months). As we can see from the results of the checks, the complexity of the support, security and reliability of the code in general is at a good level, up to SonarQube standards.

Most importantly, this approach has proven beneficial as there have already been several cases where SonarQube found errors for the team. We continue to develop. In particular, soon we will check backend and mobile application libraries’ licenses in this way. In the future, we are thinking about using it for information security and the frontend.

Objectives for the near future

One of the hottest trends for us right now is the introduction of Trunk-Based Development and feature flags. An important innovation of new projects is that teams create separate repositories for each microservice. This greatly simplifies separate deployment. The positive effect is emphasized when combined with microservices templates, which offloads developers’ hands.

Autotest coverage, without which it will be difficult for teams to deliver features to users quickly, is a part of this area, where the key goal for the near future is to cover critical feature sets with autotests.

Finally, our teams are increasingly using C4 architectural notation. And although no one is working based on a manual yet. We have already gained the main advantage of this approach, namely, automatic creation of documentation during development.

Teams have eliminated the need to maintain diagrams in separate knowledge bases, and architecture data is updated automatically. Regardless of which tools the teams use (some now work with PlantUML, others with MermaidJS).

At the moment, we are already seeing positive results from working with all the technologies on which we opted to build our platform last year. Most importantly, there has been a positive response from the teams themselves, who are really finding it easier to work with. This means an incentive to spread this experience further.