Knock Knock! Who’s there? microservice

The microservice architecture has made a strong impression on the minds of developers. But on the market, all this does not always cause a lot of enthusiasm. All this, let’s say, is a well-known truth. But how to be? You have to manage it somehow.

What tools do the vast majority of companies have to manage development? Of course the Atlassian stack (Jira + Confluence).

Atlassian is good because it has plugins for all occasions, almost Spring Boot)) But the current realities (and the price, and tying to plugins that may stop supporting) impose some restrictions. But what if you make control only on what is, as they say, “out of the box”?

So what kind of pain do we want to solve, why are we doing this at all:

1. Reduce entropy in codebase repositories.

2. Control and record what and when goes to the prod.

Solution:

We start a new project in Jira, which will show the status of deployments in production. Each Jira project has a unique set of components. So you can imagine that a component in Jira == microservice, and if there is also a rule that one repository == microservice, everything gets even better)

But let’s not keep a register of microservices in Jira, shall we? No, of course, this is inconvenient and Jira is not about documentation and registries, there is Confluence for this.

Then we create a new space in Confluence and it will be a directory (master data, NSI or whatever) of our microservices. This space is ONLY for that! That is, 1 page == 1 microservice passport. We make a passport template (templates in Confluence) and voila, we have two objects, which, if connected, you can get both a description of the object (passport) and its status (what and how often is deployed).

In order not to synchronize directories by hand, it is enough to write a script that will periodically synchronize Confluence with Jira.

All! Now you can only deploy things that have a passport (if you make the component field required 😉 )

Then you can make many different features on this solution:

1. We integrate with CI\CD. You can automatically generate tickets in Jira on build and before delivery. All the same, not everyone lives on solutions – PR in master, automatic code in prod.

2. You can manage the creation of repositories. That is, “first a passport, then a turnip.” This helps, among other things, to manage the architecture, because it eliminates the creation of unmanaged code.

3. You can use fats in tickets to auto-assign to the owner’s code, by specifying it in the card and filling it with the same script, for example.

4. The structure in the Confluence space can be controlled by the classification of microservices (separate backend from clients, separate by systems, etc.)

5. and much more that will solve specific pains, a specific team.

What would you like to show? That the management of microservices and the integration of their passports into development and operation processes can be implemented even on basic tools. Because architectures, code implementation, documentation are often discussed, but “embedding” all this into the daily routine to ensure the relevance of the data is often overlooked, and this is an important step in engineering.