How to properly release in large companies?

Question

Project management

Hello everyone
Development is carried out by teams. Those. each team has its own direction, its own specifics, and often even its own technology stack. Releases went by teams, but with an increase in the number of tasks, the number of developers and the connectivity of features with several teams, problems began to appear. Those. for example, one team does their part quickly and waits a couple of weeks for the other team to do theirs. As a result, obsolete code and delays in releases.
Familiar developers proposed the following schemes:

1. A feature team where developers get together to implement one feature. However, there are disadvantages and difficulties here, if there are a lot of features, they are small and short-lived. Plus, "monorelease" is quite difficult to test if everyone from different teams is shoved into it
   
2. Versioning. The commands are released separately, but you need to make additional code and clean it up from time to time. Which again leads to some difficulties and higher development costs.
   

What is the right thing to do in such situations? What is the best practice?

Answer 1

1. Feature-team is a good tool for a manager to synchronize technical solutions and, accordingly, reduce risks. I don't believe in simultaneous releases by different teams.
2. With "versioning" it seems to me that there are not so many difficulties in fact.
If we perceive the result of the work of each command as some kind of service with api outside (and it probably is), then in fact the teams are required to ensure backward compatibility of new api versions with old ones - a task that is useful in any case.
Doing versioning without backwards compatibility is a very bad idea in my opinion. Here are the costs of support, and the costs of reconnecting for all other teams.
It is also very important that there is a sane CTO / architect of this entire zoo. Or at least it was just.
I saw live projects where the general architecture was not thought out - the 2nd layer was written on top of the layer of basic services according to business requirements, a year later the 3rd layer was written on top of the 2nd layer, ... as a result, by our era there were ~ 12 layers and I didn’t know exactly how it works it seems no one - which, however, did not prevent the project from having tens of millions of users.

Answer 2

At RIT ++ this year there was an excellent (in my opinion) report from Andrey Evsyukov from Lamoda . I recommend taking a look. Alas, there is no record, but I think the original essence will be clear from the slides.
By the way, it is your problems (Time-to-market) and part of your fears that are considered there.

Answer 3

There is a concept of a release cycle. Each cycle implies a deterministic number of changes made to the product.
For each release, a set of interfaces between components is declared. In different projects, this is implemented in different ways, for example, the web uses tools like Swagger.
There is an architect who is responsible for the overall interface. It declares the version, for example 1.0.5. Backend and front-end are sawn under the corresponding version of the interface. If one team fails, the 1.0.4 release occurs, i.e. what is ready or the release is delayed.
Typically, multiple versions of an interface can be declared.
Large and complex projects use a modular approach. Each team is responsible for its own component of the project and has a project coordinator. He is responsible for the release. In any case, the prepared release goes through the test team, etc. Just like that, raw code does not get into production.

Answer 4

How to properly release in large companies?

What you describe indicates poor planning. There should be a project manager who organizes the planning process in which Product Owner, Team Leads of all groups and himself will participate. The result of planning should be a Gantt chart or Roadmap, which will take into account the relationship and will include adequate risks. I do this all the time, and I almost never have blockers like you describe on my projects.
There are different methods for release.
Versioning is good if you work through the API, and if you have several backend commands that are sawing the same monolith, then you need to implement the GitFlow practice and install a technical lead who will merge branches into releases and correctly build an adequate GitFlow.
API versioning is a great practice, you need to learn it and not listen to those who say that it is difficult. It's not hard. And versioning will allow you to release the backend without waiting for the frontend and without breaking it in production.
In order for the releases to go smoothly, you need to immerse yourself in books on Continues Delivery and dockerize your services or monolith.

Answer 5

The correct versions are the more versatile option. In addition, the same feature teams can work with versions as well.
To make it easier to work with versions, use https://semver.org/lang/ru/
Let's just say. Organizing effective feature teams will take more effort than versioning.

Answer 6

Many recommend permanent commands. Those. a feature team is not going to a feature, but a feature is assigned to the team. After the development of a feature, the team remains the same, it is just given a different feature.
You can do "internal operansource" - let's say you have component commands, but at the same time, one team needed a feature in the component of another team. She can propose a patch for this component, and the other team will consider it, roll on the component, or reject it.
see also
https://www.thoughtworks.com/mingle/scaled-agile/2...
www.discussagile.com/blog/dependency-management-in...
https://www.scaledagileframework.com/value- stream-...

Answer 7

well, now the approach of getting rid of cohesion and creating an architecture based on a large number of microservices that can be easily modified, regardless of the actions of other teams, is popular.
accordingly, development can be carried out in parallel, as well as deployment with testing.