The long long fourth day is over, but we're not in a hurry, so let's discuss the third.
The first talk of the day about release trains from Yandex.Disk. I made sure that our Dodo variant is quite effective, we don't complain much. Automation of publication to stores hasn't been sold to me yet. Although if you publish 6 different builds across different stores once a week, I would also think about it. When the release is once every 3 weeks to one and a half stores, then it doesn't seem worth it.
It was interesting to discuss the approach to filling Release Notes in these release trains. Automatic creation of tasks for product managers and, accordingly, for marketing is proposed, without which the train won't leave. I think we'll go this way, otherwise our users are clearly tired of "new tariffs" for more than half a year in each release. And ideally, no one wants to write release notes.
Against this background, we also discussed the mentioned trunk-based approach to git. But I still haven't determined for myself the line of test coverage starting from which it's not scary to pour everything without testing into the common branch (requesting your favorite material on this topic, I want to get into it). Our git flow-like approach clearly has scary overheads in the area of CI pipelines and testing on merge requests, but for now it gives us such guarantees that QA on regressions doesn't have to recheck all recent changes. Where there's trunk-based, there are feature toggles, so I took away from chats for reflection on how to formulate such a policy so that their number doesn't grow as uncontrollably as it happens by default.
The second session was a round table where it was discussed what the CI/CD process looks like in small, medium, and large companies. And naturally, everything slid into discussing some wildness of a large company because everyone is interested. From the point of view of broadening horizons and to realize some crazy scale, this is probably useful, but not very practical. Even the described "medium" project, from my point of view, already looks like super advanced, this was not very pleasant. I managed to collect ideas bit by bit on what to play with. I wanted to drag dependency-guard to us, play with dependency-analysis and talaiot, and on top of that dive into some impact analysis. Not that this will bring us some crazy profits in the short term, but for the purpose of self-development, why not.
Another thought voiced at the round table that still haunts me: green develop is guaranteed only by queues of merge requests for merge provided that all checks are also run on them. And if you want MRs to also move quickly from push to merge, this is generally utopia rather. From this I concluded that processes for getting out of bad situations are probably in most cases even more important than protection from getting into these bad situations. Which however is not news, but precisely in terms of working with git and tickets I apparently haven't thought about it yet. So it's better to break the common branch once every few months or let a problem into the release, but have a process to quickly fix it and always work stably quickly, without fanaticism in reliability.