How realisitic in large companies?

Hello

Development is done in teams. Ie, each team has its own focus, its own peculiarities and often even your technology stack. Releases were teams, however, increasing the number of tasks, the number of developers and connectivity features with multiple teams, began to appear the problem. Ie, for example, one team is doing their part quickly and waiting a couple of weeks, while the other team will do mine. In the end, the deprecation of code and delays in releases.

Familiar developers suggested the following scheme:

  1. Feature-Tim, where the developers are going to implement the same features. However, there are disadvantages and difficulties, if the feature a lot, they are small and short. Plus "monorails" is quite difficult to test if he shoved all in different teams

  2. Versionnode. Team realizada separately, but need to do additional code and from time to time to clean it. Which again leads to some complexities and the rise in the cost of development.


How in such situations to do? What is the best practice?
June 3rd 19 at 21:03
7 answers
June 3rd 19 at 21:05
1. Feature-Tim it is a good tool of Manager, to synchronize technical solutions and reduction of risks. In simultaneous releases of different teams I believe.

2. With "versioning" I think it is not so much complicated actually.
If you perceive the result of each command as a service with api to the outside (and probably is), then in fact the team is required to provide backward compatibility of new versions with the old api, - a task which in any case useful.
To do versioning without backward compatibility - a very bad idea I think. Here and support costs, and the cost of reconnection of all the other teams.

It is still very important to a sane CTO / architect of the entire zoo. Or at least were just.

Seen live projects where there was no thought of the overall architecture is the top layer of basic services on the business requirements were written in the 2nd layer, in a year on top of 2nd layer was written 3rd, ... in the end to our era of the layers was ~12 and how it exactly works to know that I think no one - that however did not stop the project to have tens of millions of users.
June 3rd 19 at 21:07
At RIT++ this year was perfect (in my opinion) the report from Andrey Yevsyukov from Lamoda. I recommend to look. Alas, no recording, but the slides I think would be understandable source the essence.
By the way, there are considered it is Your problems (Time-to-market) and part of Your fears
June 3rd 19 at 21:09
There is the concept of release cycles. Each cycle involves determinirovannogo the number of changes made to the product.
For each release, declares a set of interfaces between components. In different projects this is implemented in different ways, such as web tools are used like Swagger.
There is the architect who is responsible for the overall interface. He declares version, like 1.0.5. Backend and front-end sawn under the appropriate version of the interface. If one team does not have time, there is the release 1.0.4, ie that the finish or the release is postponed.
Usually can be declared multiple versions of the interface.
In large and complex projects using modular approach. Each team is responsible for its own component of the project and a project coordinator. He is responsible for the release. In any case prepared release goes through a QA team, etc. Just the raw code in production does not fall.
June 3rd 19 at 21:11
How realisitic in large companies?

What you describe indicates a weak planning. Needs to be a project Manager who organizes the planning process will involve Prodakt Ovner, Teamleads group and himself. The result of planning should be the Gantt chart or Roadmap which would take into account relationship will be established and adequate risks. I always do, and my projects almost never is such the blockers as you describe.

About realisitic, there are different methods.
Versioning is good if you are working through the API, but if you have several teams of backend are sawing the same monolith it is necessary to introduce the practice GitFlow and put tahlia to deal with mariami branches in the releases and correctly build adequate GitFlow.

Versioning of API is a great practice, she needs to learn not to listen to those who say that it is difficult. It is not difficult. And the versioning will allow to release the backend without waiting for the frontend and not breaking it in production.

What would the releases went smoothly you need to immerse yourself in books on Continues Delivery and activities dobereshsya their services or monolith.
June 3rd 19 at 21:13
Correct version - more versatile option. In addition, the same feature-tims can work and with versions.
To simplify the versioning, use https://semver.org/lang/ru/

So to speak. Effectively organize and manage a feature-Tim will take more effort than versioning.
June 3rd 19 at 21:15
Many recommend permanent team. Ie feature Tim is not going to feature, but the team is assigned to the feature. After the design features the team remains the same it is just another feature.

You can do "inner OpenSRS" - suppose you have component teams, but one team needed feature in a component of another team. It can offer a patch for this component, and the other team will see it inflated to a component or reject.

see also
https://www.thoughtworks.com/mingle/scaled-agile/2...
www.discussagile.com/blog/dependency-management-in...
https://www.scaledagileframework.com/value-stream-...
Permanent team.

And how then to deal with the following problems:

The team comes to the task where you don't need any developer. What about the downtime?
The team comes to the task too big in the end either you have more people to pull or stretch the Tusk into two teams - then again, consistency is needed and there is a potential delay that someone from the team will do it faster. - Shanie_Armstrong98 commented on June 3rd 19 at 21:18
To create a backlog of tasks - the developer takes the following task. Or helps to make the current (testing, writes tests or build scripts etc.) - Roderick_Quitzon56 commented on June 3rd 19 at 21:21
June 3rd 19 at 21:17
well, now a popular approach of getting rid of connectivity, and creation of architecture based on a large number of microservices that can be easily modified, regardless of the actions of other teams.
accordingly, the development can be conducted in parallel, as well as deployment testing.
which can be easily modified, regardless of the actions of other teams.

"really?"

if you do not change the API, Dima, only "no problem". And it's fantastic for the developing of the project.

By the way, if you do not change the API, even in a single monolithic application can also work seamlessly on the code. - Shanie_Armstrong98 commented on June 3rd 19 at 21:20
in the same solid, describes approaches to change API usage is not the logic of the other parts. - Roderick_Quitzon56 commented on June 3rd 19 at 21:23
,
if you do not change the API, Dima, only "no problem". And it's fantastic for the developing of the project

The microservices so good that they are accessed in a known manner. You need to change the API - make the new version of micro service, hanging it to the new address, and then slowly translate using this micro service modules to the new version without touching the old one until the end of migration. Also may be difficulties, of course, but compared to the monolith... - Zoey_Oberbrunner6 commented on June 3rd 19 at 21:26
the IPA also develops of course, but I'm sure once you have at least had a prototype, you can evolutionary change the API without affecting the rest of the product, with some fundamental changes in the API to do well, not more than once a year, I think this is enough to comfortably develop the product. - owen.Block commented on June 3rd 19 at 21:29
,
in the same solid, describes approaches to change API usage is not the logic of the other parts.


the microservices solve a very different problem - the problem of horizontal scaling.
and the problem of default is also solved exactly as microservices and monoliths. - chelsea13 commented on June 3rd 19 at 21:32
,
The microservices so good that they are accessed in a known manner.


exactly no different from a set of public functions/methods/classes for the individual subsystems of the monoliths. - owen.Block commented on June 3rd 19 at 21:35
if you don't need to develop the project and will never need to rewrite a part of these sets in another language, say, or move to another server - can be anything... - Zoey_Oberbrunner6 commented on June 3rd 19 at 21:38
,
if you don't need to develop the project and will never need to rewrite a part of these sets in another language, say, or move to another server - can be anything...


good excuses already and come up with cases on the go.

the use of microservices - only in horizontal scaling, as I already wrote above.
and not in the solution of those problems that the default ozvucheny.

rewriting into another language - no problem, if your code in the monolith was originally with well-defined internal APIs. - Zoey_Oberbrunner6 commented on June 3rd 19 at 21:41
the problem of TS - asynchronous operation teams. The micro service, as I wrote above, helps the team, he wrote, to test it and roll out a release without waiting for the team working on the code accessing this micro service. Because the old version continues to run as long as necessary for migration.

Well, as you will rewrite in another language a couple of methods of one class, without touching anything else - I can't even imagine going... - chelsea13 commented on June 3rd 19 at 21:44
heh differs fundamentally
the micro service exists independently of ANY other system in the monolithic architecture of the subsystem cannot exist independently, because of this and all probelmy, because of this and the ability to easily scale the monolith.
a microservices - not solve one problem and a large layer of problems, maltabarova this is probably one of the most main of which should be parallel/independent development, testing, deployment, in General, solves many problems and creates (additional overhead, duplication of code, the more you should write)
for those who have used a monolithic architecture to do, of course nothing like the monoliths can be no other approaches than does not differ from the monoliths (after all, the fact that accustomed to and what you do best work) - Zoey_Oberbrunner6 commented on June 3rd 19 at 21:47
,
Well, as you will rewrite in another language a couple of methods of one class, without touching anything else - I can't even imagine going...


rewriting a couple of classes in another language is utter stupidity.
you have just added microservices (in comparison with the monolith) tying for microservices and latency it will take much more resources, nothing vyhodite. - chelsea13 commented on June 3rd 19 at 21:50
,
problem TS - asynchronous operation teams. The micro service, as I wrote above, helps the team, he wrote, to test it and roll out a release without waiting for the team working on the code accessing this micro service. Because the old version continues to run as long as necessary for migration.

and?
why is this impossible to do with the monolith? - owen.Block commented on June 3rd 19 at 21:53
,
because of this and the ability to easily scale the monolith.


1) Yes, but it's the only thing plus microservices.
2) you wrote these things already in explanation of my words above I've printed in bold twice the idea. so the value of your words is not large.
3) it is irrelevant to the problems of default. - Zoey_Oberbrunner6 commented on June 3rd 19 at 21:56
let's stop doing deep Analytics on coffee grounds. - Zoey_Oberbrunner6 commented on June 3rd 19 at 21:59
,
>rewriting a couple of classes in another language is utter stupidity.
understand until you've read all these books about "code complete" how to reduce latency, and not to write too much studs, studied all these DRY, KISS.
The world has changed. In this world, add latency through microservices, rewrite a couple of classes using the new language and duplicate the code in the services and doing other at first sight nonsense. Who lives in the old world, do not understand why they do it - Zoey_Oberbrunner6 commented on June 3rd 19 at 22:02
Why is any architectural question like to push the microservices? The breaking of the packages and the semantic versioning, that's a reasonable solution - chelsea13 commented on June 3rd 19 at 22:05
The world has changed. In this world, add latency through microservices, rewrite a couple of classes using the new language and duplicate the code in the services and doing other at first sight nonsense. Who lives in the old world, do not understand why they do it


That is, if the programmer is not capable of decomposition and normal public interfaces within a single code base monolith, the transition to microservices just leaves him no choice?
But what is the quality of the decomposition is, if programmers are to talk as you? - owen.Block commented on June 3rd 19 at 22:08
,
The microservices so good that they are accessed in a known manner. You need to change the API - make the new version of micro service, hanging it to the new address, and then slowly translate using this micro service modules to the new version without touching the old one until the end of migration. Also may be difficulties, of course, but compared to the monolith...


There is no difference with the one to "go there" inside a monolithic application that inside microservices system.

You can't keep self-discipline to limit yourself to contacting the components in the monolith, past the agreed API? Yes, Yes, Yes, all public classes, this is the internal API. - lois.Gusikowski11 commented on June 3rd 19 at 22:11
and what figure is visible in the middle of where you based your analysis? Put a screenshot or something... - ansley commented on June 3rd 19 at 22:14
,
the micro service exists independently of ANY other system in the monolithic architecture of the subsystem cannot exist independently, because of this and all probelmy, because of this and the ability to easily scale the monolith.


This is only an internal psychological problem in the brain of the programmer.

You here write that the problem is solved:

in the same solid, describes approaches to change API usage is not the logic of the other parts.


But it seems that you do not understand about what speech. - jarret commented on June 3rd 19 at 22:17
,
and what a figure is visible in the middle of where you based your analysis? Put a screenshot or something...

That is, you do not understand that a call to a separate component within the monolithic application is logically equivalent to calling the individual service in microservices system?

To a component in a monolithic application, we unknown way, whether that appeal? What do you mean here?

The microservices so good that they are accessed in a known manner.


No, I do not argue, there are different programmers and many a mess in the code. And when the codebase is unified, the opportunity to litter with the incorrect bunch of components will be bigger.

But since that's a microservices to deal with the insufficient isolation of components... It's overkill. When a simple ruble/dollar to squeal on the head with these nedoprogrammisty to not climb into the components by the agreed set of public interfaces of a component. - chelsea13 commented on June 3rd 19 at 22:20
the challenges in the monolith can no different from calls to microservices. The question is can the components exist separately from the whole system?
if you can then this is microservice architecture, not a monolith, if not then it remains a monolith with all its shortcomings - jarret commented on June 3rd 19 at 22:23
,
The question is can the components exist separately from the whole system?
if you can then this is microservice architecture, not a monolith, if not then it remains a monolith with all its shortcomings


What shortcomings, in the context specified at the top of the page for the question about the complexity of the release?

About horizontal scaling is not necessary, it is to the question posed is not relevant. - jarret commented on June 3rd 19 at 22:26

Find more questions by tags Project managementWeb DevelopmentOrganization of the work