Короче, я уже совсем поплыл с зарплатами и делаю вывод, что часто надо просто уметь себя продать

Мне кажется, что в данной ситуации да Ну или 300к много для автотестера При разном уровне требований к работникам.

А потом такие «не, ну на эликсир никого не найти»

Привет! А в devops какие сейчас бест праксис, где хранить helm/terraform? В том же репозитории, где и код приложения или в отдельных?

Привет! А в devops какие сейчас бест праксис, где хранить helm/terraform? В том же репозитории, где и код приложения или в отдельных?

Привет! А в devops какие сейчас бест праксис, где хранить helm/terraform? В том же репозитории, где и код приложения или в отдельных?

Привет! Да, мы храним в той же репе. Это очень удобно

У меня есть один человек в команде, мечтающий разбить всё на 10-ки реп 😂

У меня есть один человек в команде, мечтающий разбить всё на 10-ки реп 😂

Я тоже сторонник монореп. Основной аргумент за мултирепы это то что проще настраивать CI

А зачем?

Его аргументация, что у приложения и терраформа разные life cycle. Терраформ должен отображать инфраструктуру.

А причём тут репозитории?...

А причём тут репозитории?...

Я работал на проектах, где инфраструктура была в отдельных репах И я работал на проектах, где инфраструктура была в той же репе, что и проект (и его фронтенд и всё-всё-всё) Особой принципиальной разницы я не почувствовал. В плане удобства, к мултирепам и правда чуть-чуть проще писать CI, зато гораздо сложнее менеджить версии конечного варианта

Я сталкивался со первым и это была боль. С тех пор, как я делаю исключительно монорепы - проблем больше никогда не было.

я чего-то не понимаю или второе и есть монорепа

Поэтому и было интересно, есть ли какие преимущества у не монорепо подход

А причём тут репозитории?...

Мне кажется, монорепа наоборот получила большую популярность, потому что в ней проще настраивать CI и инфру, т.к. у тебя просто директория со всем сразу.

CI в монорепах сложнее сделать эффективным. Нужно очень аккуратно хэшировать код и зависимости, чтобы не запускались юнит-тесты на бэке, когда ты меняешь фронт

Тут есть два фактора. 1. Ты разрабатываешь каждое отдельное приложение и инфру независимо. 2. Отдельные элементы функционала связаны между приложениями (например, тебе может понадобиться поддержка какой-то вещи на сервере, когда ты пилишь что-то на клиенте или когда добавляешь какой-то новый элемент инфраструктуры). В итоге проще всего с точки зрения разрабоки это менеджится, когда у каждого отдельного компонента есть какое-то подобие версионирования, где ты можешь сказать, что с такого-то момента этот компонент поддерживает функционал N, соответственно, мы можем реализовать зависящую от этого функционала фичу в другом компоненте. Команда разработки первого функционала может реализовать эту фичу и забыть о ней. Потом придёт команда разработки второго компонента и продолжит работу над этой частью системы с их стороны. Добавить фиксы в первый компонент, если это необходимо, не проблема. При этом, когда мы имеем монорепу, у нас получается мусорка на этом этапе интеграции, потому что всё неизбежно скатывается в долгоживущую ветку, в которой работает несколько человек.

Хз. В гл это делается просто: only: changes: - web/**/*

> всё неизбежно скатывается в долгоживущую ветку, в которой работает несколько человек. А что если я тебе скажу, что можно заиметь ветку типа feature_in_mulitple_components, а от неё бранчеваться с feature_of_component_1, feature_of_component_2 и т.д.

Что это поменяет, если ты не мёржишь нерабочий код в мастер? Ты же всё равно мёржишь сначала в долгоживущую ветку.

А зачем мёржить нерабочий код в мастер???

Тут поинт в долгоживущей ветке.

И как раз таки фичи, которые пилятся для нескольних компонентов, гораздо проще пилить в монорепе, чем в мультирепе

Ага. Особенно когда вы хотите потестить какую-нибудь штуку. В отдельных репах ты просто говоришь человеку переключиться на ветку, и он продолжает работать с кодом своего приложения. В монорепе для таких случаев приходится либо извращаться, либо пушить тестовые коммиты нонстопом.

А что не так с долгоживщей веткой-то?

Это антипаттерн, который приводит к боли.

В каком месте это антипаттерн-то? Взгляни на любой большой софт — у всех у них есть долгоживущие ветки. Посмотри на linux, например. В этом проекте точно знают как правильно пользоваться гитом

Как ты думаешь, как расшифровывается аббревиатура CI, и что в это понятие изначально вкладывалось?

Давай сразу к делу, твои аргументы пока что итак очень жидкие

https://martinfowler.com/articles/branching-patterns.html Можешь почитать для просвещения.

> martinfowler Попробуй ещё раз

В каком месте это антипаттерн-то? Взгляни на любой большой софт — у всех у них есть долгоживущие ветки. Посмотри на linux, например. В этом проекте точно знают как правильно пользоваться гитом

У тебя есть проблема: фича должна запилиться транзакционно в нескольких компонентах. То есть набор компонентов будет валидным либо когда эта фича присутствует во всех компонентах, либо ни в одном. Например, ты меняешь апи, и меняешь его на фронте и на бэке. В случае с мультирепами, у тебя случится вот что: у тебя будет условие типа system_is_valid = (L1 < version(component1) < R1) and (L2 < version(component2) < R2). Это ещё нормально работает, когда фича одна, но когда фичей несколько, это получается очень душно. Решение такой задачи для N компонентов с зависимостями, строго говоря, O(N!), что душно даже для компьютера, не говоря уже про человека В случае с монорепами, у тебя отсутствует вообще проблема поиска подходящих версий: всё что в долгоживущей ветке (она не обязательно должна быть долгоживущей, это типа такая транзакция), вмерживается в мастер межкомпонентный, когда фича для всех компонентов готова. Задачи поиска совместимых версий тут просто нет

А потом ты либо сталкиваешься с проблемами синхронизации в команде, когда постоянно ребейзишься, чтобы избежать конфликтов, либо внезапно у тебя всё ломается, когда ты эти конфликты пытаешься решить при одном мёрже. А с долгоживущими ветками конфликты неизбежны, если вы пилите больше одной фичи параллельно.

На самом деле, проблема существует в обоих кейсах (что с монорепой, что без). И в обоих случаях это решается одинаково — через фичефлаги. Только с таким подходом у тебя пропадает концепция общей ветки, в которой есть готовая фича.

C мультирепой легче разворачивать энв под фичу.

Моё разворачивание энва под фичу в монорепе: git clone project && cd project && docker-compose up

Представь ихний docker-compose up

C мультирепой легче разворачивать энв под фичу.

у меня прост flake.nix в поддиректориях

Представь ихний docker-compose up

Когда у серокелла уже будет какой-нибудь годный опенсурс на эликсире, кстати? Я видел либы, но они были какие-то скучные

мой соучередитель против эликсира

хз почему