DevOps это про культуру. А вы рассказываете про Опс. Что же вы 10 лет википедию не открыли? Культуру нельзя аутсорсить, её надо вырастить и внедрить в днк команды.
Все остальное в статье про ОПС. А про отдельный опс мы знаем только то, что 100% это будет боль и страдания. Именно по тому и появился DevOps.
+ Аутсорсерам по умолчанию не выгодно решать для вас проблему до конца. Им важно вас посадить на иглу и доить.
Ну и отдельным бонусом, это менталитет Опсов. Эти ребята при всей своей экспертности смотрят на картину совсем под другим углом. А в экономиках масштабирования это очень не правильно.
Решение этой проблемы - изменение культуры, опять же. Но это про пресловутый аджайл и коллаблрацию, которые только единицы СТО умеют строить(я про Европу сейчас, мне кажется в РФ с этим получше должно быть)
Ну можно еще изначально брать без подсветки все... Я себе собрал системник в прошлом году вообще без подсветки. Единственное что светится там - это видюха, но ее не я брал. Возможно у вас ограничен ассортимент и выбора мало, но теоретически он есть. Ну и не берите самое дешевое. Берите качественное.
Это все очень контекстуально и зависит от того как вы собираете документацию, как структурируете код. Уверен можно выделить что-то общее и в модулях оставить только то что относится к ним и собрать нужную версию для релиза.
Обычно разработчик в курсе, какую версию он меняет и может отличить ее от другой в коде. Варианты когда разраб был пьян или потерял очки и не рассмотрел цифру я сразу отметаю как не конструктивные.
Version Controll не про артефакты - он про изменения в коде и обмен им с другими разработчиками.
Артефакты - это результат работы вашего пайплайна. Какой бинарь соберется в итоге из кода, какие зависимости подтянутся, какой пдф отретндерится, Docker image и тп - вот это все вместе - артефакт. И хранятся они в другом месте, не в VCS. Github Releases например - продукт гитхаба, а не гита.
Сам код в большинстве случаев еще не артефакт. Разве что он не имеет зависимостей и тестов. И то с натяжкой, т.к. не каждый файл пользователь использовать может. Если для этого нужен компилятор - это не артефакт.
Допустим, что сложность управления бранчами и навигации по файлам одинаковая. Но как это меняет процесс работы? Имея инструменты навигации по файлам, помощь IDE, возможность использовать CI\CD на полную, автоматизация проверок, т.к. все в 1 месте - перевешивает все остальное.
Я не могу вас убедить словами, вам надо прожить этот опыт самому. Заставить я вас тоже не имею права.
Так и есть. Так же приходится версионировать переменные окружения, инфраструктуру и т.п. Но не все данные должны находиться в репе. Все это про принципы Чистой Архитектуры и 12 факторных приложений.
Допустим, мы справились с модулями и положили все в репу. В этом случае изменения локализации - это 1 коммит. + у вас есть возможность инструментами вашей среды проверить все места использования ключа перевода. Множества версий можно про разному обслуживать, зависит от вашей фантазии - несколько файлов или пулл переводов из системы локализации во время билда. Все равно 1 коммит и просто проверяется. Переводы тут же оказываются у всех разработчиков, что снижает шанс конфликтов в коде.
В общем, я уверен идею вы поняли, не буду давить. Конечно у вас уже есть какой-то код и процесс и менять его - это не бесплатно. Изменения это всегда больно - отказываться от привычного поведения это больно. Но хотя бы проведите мысленный эксперимент.
Если у вас сразу несколько версий в проде - значит надо относиться к ним как к актуальным. Т.е. хранить их код в 1 репе в 1 бранче в разных модулях. Тут работает та же стратегия что и с версионированием API.
Да файлов одновременно у разработчика станет больше локально. но процесс - сильно проще. К тому же это позволит вам переиспользовать код гораздо эффективнее.
Если версии сильно завязаны на версии модулей и не билдятся с одними зависимостями - вот тут бы делать другую репу... т.к. это другое приложение.
Возможно в этом случае стоит отделить только какое-то ядро приложения и обьявить контракт, для интеграции с другими компонентами.
Но все это билдится без через гитхаб флоу и тп. все это проще чем Гит Флоу.
У меня нет ни малейшего сомнения, что вы заставите это работать технически. Многие уже делали.
Суть в том, что практически в 2025 году мы видим на популярном ресурсе статью, в которой рассказываю про Гит Флоу как актуальный метод работы, хотя он уже как 5 лет признан автором и комьюнити устаревшим и имеет пару преемников.
И они появились не просто так, а по тому что они проще и удобнее. Разработчикам не надо думать "в какую ветку сейчас пушить?" и не надо использовать дополнительный инструмент. Что упрощает ежедневную работу и ускоряет поставку.
А в чем проблема с "замусориванием" - ветки не удаляются? Теперь вы предлагаете вообще мульти-репу... Это еще больше усложняет подход. Тем самым вы практически сделаете невозможным CI.
Да и зачем что-то тянуть к себе локально из разных реп, когда это все должно храниться в 1 репе и тестироваться в пайплайнах? У меня все больше вопросов к вашему процессу сборки, тестированию и деплоя. Но углубляться в это в комментариях не лучшая идея. Если кому интересно можете постучать в личку.
Но в целом этот процесс далек от CI\CD и от Continuous Delivery.
Gitflow is a legacy Git workflow that was originally a disruptive and novel strategy for managing Git branches. Gitflow has fallen in popularity in favor of trunk-based workflows, which are now considered best practices for modern continuous software development and DevOps practices. Gitflow also can be challenging to use with CI/CD. This post details Gitflow for historical purposes.
И разберитесь как правильно использовать Git merge vs rebase. Если коротко, то Rebase можно использовать ТОЛЬКО если вы еще не делились своей историей, не делали push. Все остальное время вы делаете merge.
Чистота коммитов - это не то о чем надо заботится в репе. Репа это про изменения в коде, и нет смысла их прятать. Разве что вашим разработчикам стыдно показывать свою работу другим. Но это к психологу. В остальных же случаях, когда говорят про чистоту коммитов, имеют ввиду порядок коммитов для системы релизов. Чтобы коммиты-релизы шли один за другим по порядку. В этому случае - у вас не доделанный пайплайн. Релизы это не про коммиты. Добавьте гит тэги, если их нет. Или уберите, если вы тэгаете все подряд.
Извините что так резко, у меня ПТСР после всего этого. но переписывать уже лень.
Понял. Ну как сказать... не все что делается - лучшая практика. Иногда это просто то что делают все...
ИМХО этот тайтл появился из-за размытия понятия QA, чтобы отделить мануальщиков, от автоматизаторов - не более. Чтобы было проще нанимать людей со скилом в программировании.
Тут срабатывает как раз тот вариант, когда QA могут писать Acceptance тесты, в репе с кодом. Но тут надо следить, чтобы QA соблюдали практики написания кода разработчиков (или если они более скиловые - предлагали свои). Но владение кодом должно быть общим и по большей части - у разрабов.
Это про то, что разрабы по итогу будут запускать эти тесты, чтобы понять все ли они правильно сделали. И если тест падает без очевидной причины - им надо разобраться в чем именно проблема.
Т.е. роль вполне себе актуальная.
Правда когда ее внедряют в Вотерфольных организациях это превращается в противоположность, когда QA отдельно и разрабы отдельно. Возвращаемся к вопросу о скорости фидбека.
Не верно. QA все так же нужны - их роль возвращается к их ключевой компетенции - они пишут тестовые сценарии, определяют классы эквивалентности, выполняют исследовательское тестирование, чтобы найти возможные косяки. Ревьювят тесты.
Все это добро они приносят разрабам. Разрабы это все кодируют - профит.
Конечно никто не запрещает QA писать код, если у них есть такой скил. Но это тоже должно быть правильно организовано. Все-таки разрабы больше знают про то как написать поддерживаемый код. Не каждый тестировщик этим интересуется.
Тут еще важно правильно организовать код и тесты в репе. Т.к. тесты ломаются когда меняется код. А код меняют разрабы. Значит им его и чинить. Иначе получается нездоровая динамика - сокрытие информации от разрабов, когда они не знают работает ли система, пока не запушат все и не увидят лампочку...
Все тесты должен писать разработчик - это ваш специалист по коду. QA только приносят ему готовые спецификации\сценарии тестов - специалисты по качеству же. Вместе, вы как команда ответственные за качество продукта.
e2e тестирование тоже выполняется разработчиками. И вы правильно заметили, про скоуп по 1 сервису. Т.к. Ваши сервисы по умолчанию должны быть Независимыми - тестируются и деплоятся отдельно от остальных. А то чего вы на самом деле боитесь - интеграция сервисов, покрывается Контрактными Тестами.
Конечно у вас должны возникнуть вопросы к правильности архитектуры ваших сервисов, их границам.
Иначе, скорее всего у вас так, - у вас появятся огромные тестовые стенды с полным поднятым окружением. Еще хуже, когда их становится больше чем у вас команд.
Рекомендую к просмотру видео Dave Farley - соавтор методологии Continuous Delivery, а конкретно про e2e тестирование и Acceptance тестирование.
Вполне разумный подход. 90% сайтов должны быть так сделаны. Можно сдобрить htmx чтобы получить заветную интерактивность, когда придут первые деньги.
Иначе будет типичное не эффективное Г с кучей дублированного кода.
Абсолютно согласен с автором.
Вы не гугл. Вам это не надо.
DevOps это про культуру. А вы рассказываете про Опс. Что же вы 10 лет википедию не открыли? Культуру нельзя аутсорсить, её надо вырастить и внедрить в днк команды.
Все остальное в статье про ОПС. А про отдельный опс мы знаем только то, что 100% это будет боль и страдания. Именно по тому и появился DevOps.
+ Аутсорсерам по умолчанию не выгодно решать для вас проблему до конца. Им важно вас посадить на иглу и доить.
Ну и отдельным бонусом, это менталитет Опсов. Эти ребята при всей своей экспертности смотрят на картину совсем под другим углом. А в экономиках масштабирования это очень не правильно.
Решение этой проблемы - изменение культуры, опять же. Но это про пресловутый аджайл и коллаблрацию, которые только единицы СТО умеют строить(я про Европу сейчас, мне кажется в РФ с этим получше должно быть)
Ну можно еще изначально брать без подсветки все... Я себе собрал системник в прошлом году вообще без подсветки. Единственное что светится там - это видюха, но ее не я брал. Возможно у вас ограничен ассортимент и выбора мало, но теоретически он есть. Ну и не берите самое дешевое. Берите качественное.
Круто что у вас есть скил отпаять что не надо)
Ни разу. Он поставляется в разных вариантах. У меня монолитный черный без стекла, без подсветки. Могу фотку скинуть.
https://www.fractal-design.com/de/products/cases/focus/focus-2/black-solid/
не подключайте к материнке, или используйте софт для этого. Паяльник уже давно не нужен.
Fractal Focus 2, рекомендую)
Это вы про те, которые начали писать когда node.js появился?)
Это все очень контекстуально и зависит от того как вы собираете документацию, как структурируете код. Уверен можно выделить что-то общее и в модулях оставить только то что относится к ним и собрать нужную версию для релиза.
Обычно разработчик в курсе, какую версию он меняет и может отличить ее от другой в коде. Варианты когда разраб был пьян или потерял очки и не рассмотрел цифру я сразу отметаю как не конструктивные.
Version Controll не про артефакты - он про изменения в коде и обмен им с другими разработчиками.
Артефакты - это результат работы вашего пайплайна. Какой бинарь соберется в итоге из кода, какие зависимости подтянутся, какой пдф отретндерится, Docker image и тп - вот это все вместе - артефакт. И хранятся они в другом месте, не в VCS. Github Releases например - продукт гитхаба, а не гита.
Сам код в большинстве случаев еще не артефакт. Разве что он не имеет зависимостей и тестов. И то с натяжкой, т.к. не каждый файл пользователь использовать может. Если для этого нужен компилятор - это не артефакт.
Допустим, что сложность управления бранчами и навигации по файлам одинаковая. Но как это меняет процесс работы? Имея инструменты навигации по файлам, помощь IDE, возможность использовать CI\CD на полную, автоматизация проверок, т.к. все в 1 месте - перевешивает все остальное.
Я не могу вас убедить словами, вам надо прожить этот опыт самому. Заставить я вас тоже не имею права.
Так и есть. Так же приходится версионировать переменные окружения, инфраструктуру и т.п. Но не все данные должны находиться в репе. Все это про принципы Чистой Архитектуры и 12 факторных приложений.
Допустим, мы справились с модулями и положили все в репу. В этом случае изменения локализации - это 1 коммит. + у вас есть возможность инструментами вашей среды проверить все места использования ключа перевода. Множества версий можно про разному обслуживать, зависит от вашей фантазии - несколько файлов или пулл переводов из системы локализации во время билда. Все равно 1 коммит и просто проверяется. Переводы тут же оказываются у всех разработчиков, что снижает шанс конфликтов в коде.
В общем, я уверен идею вы поняли, не буду давить. Конечно у вас уже есть какой-то код и процесс и менять его - это не бесплатно. Изменения это всегда больно - отказываться от привычного поведения это больно. Но хотя бы проведите мысленный эксперимент.
Так ведь наоборот же, выделил общее изменение в одтельный класс и потом переиспользуешь в нужных местах. Куде еще проще?
Если у вас сразу несколько версий в проде - значит надо относиться к ним как к актуальным. Т.е. хранить их код в 1 репе в 1 бранче в разных модулях. Тут работает та же стратегия что и с версионированием API.
Да файлов одновременно у разработчика станет больше локально. но процесс - сильно проще. К тому же это позволит вам переиспользовать код гораздо эффективнее.
Если версии сильно завязаны на версии модулей и не билдятся с одними зависимостями - вот тут бы делать другую репу... т.к. это другое приложение.
Возможно в этом случае стоит отделить только какое-то ядро приложения и обьявить контракт, для интеграции с другими компонентами.
Но все это билдится без через гитхаб флоу и тп. все это проще чем Гит Флоу.
Спасибо за статью. Я тоже подумываю сделать что-то свое и ваши советы будут мне полезны.
У меня нет ни малейшего сомнения, что вы заставите это работать технически. Многие уже делали.
Суть в том, что практически в 2025 году мы видим на популярном ресурсе статью, в которой рассказываю про Гит Флоу как актуальный метод работы, хотя он уже как 5 лет признан автором и комьюнити устаревшим и имеет пару преемников.
И они появились не просто так, а по тому что они проще и удобнее. Разработчикам не надо думать "в какую ветку сейчас пушить?" и не надо использовать дополнительный инструмент. Что упрощает ежедневную работу и ускоряет поставку.
А в чем проблема с "замусориванием" - ветки не удаляются? Теперь вы предлагаете вообще мульти-репу... Это еще больше усложняет подход. Тем самым вы практически сделаете невозможным CI.
Да и зачем что-то тянуть к себе локально из разных реп, когда это все должно храниться в 1 репе и тестироваться в пайплайнах? У меня все больше вопросов к вашему процессу сборки, тестированию и деплоя. Но углубляться в это в комментариях не лучшая идея. Если кому интересно можете постучать в личку.
Но в целом этот процесс далек от CI\CD и от Continuous Delivery.
Уточните пожалуйста, кто вам сказал что это не альтернатива?
Не всегда флоу выбирается под процессы. Всегда имеет место человеческий фактор - кто-то нагуглил и не изучил альтернативы.
Утверждение что он "самый популярный" - никакими цифрами не подтверждается.
SWOT анализ нам тут не показали. Только хотелки в ведении. И все эти хотелки гараздо лучше решаются TBD или Github Flow.
Если для вас процессы это важно и вам нужен CI/CD то может автор Continuous Delivery вам расскажет понятнее https://www.youtube.com/watch?v=_w6TwnLCFwA
Вот цитата с сайта атласина про гит флоу:
Gitflow is a legacy Git workflow that was originally a disruptive and novel strategy for managing Git branches. Gitflow has fallen in popularity in favor of trunk-based workflows, which are now considered best practices for modern continuous software development and DevOps practices. Gitflow also can be challenging to use with CI/CD. This post details Gitflow for historical purposes.
А вот ссылка на страницу автора Гит Флоу - https://nvie.com/posts/a-successful-git-branching-model/
Просто перестаньте это использовать. Пристрелите уже лошадь.
Сколько лет этому флоу? А сколько лет уже говорят что не надо его использовать? Есть же https://githubflow.github.io/ или еще больше примеров в Trunk Based Development https://trunkbaseddevelopment.com/ . Но только не гит флоу.
И разберитесь как правильно использовать Git merge vs rebase. Если коротко, то Rebase можно использовать ТОЛЬКО если вы еще не делились своей историей, не делали push. Все остальное время вы делаете merge.
Чистота коммитов - это не то о чем надо заботится в репе. Репа это про изменения в коде, и нет смысла их прятать. Разве что вашим разработчикам стыдно показывать свою работу другим. Но это к психологу. В остальных же случаях, когда говорят про чистоту коммитов, имеют ввиду порядок коммитов для системы релизов. Чтобы коммиты-релизы шли один за другим по порядку. В этому случае - у вас не доделанный пайплайн. Релизы это не про коммиты. Добавьте гит тэги, если их нет. Или уберите, если вы тэгаете все подряд.
Извините что так резко, у меня ПТСР после всего этого. но переписывать уже лень.
Мне кажется там без вариантов. Одни должны учиться кодить, а вторые писать тесты. Прикрывать друг-друга. Это и есть командная работа.
На скрамтреке недавно хорошо про это рассказали."Награды и HR-политики в Аджайл-организациях. Илья Павличенко"
Понял. Ну как сказать... не все что делается - лучшая практика. Иногда это просто то что делают все...
ИМХО этот тайтл появился из-за размытия понятия QA, чтобы отделить мануальщиков, от автоматизаторов - не более. Чтобы было проще нанимать людей со скилом в программировании.
Тут срабатывает как раз тот вариант, когда QA могут писать Acceptance тесты, в репе с кодом. Но тут надо следить, чтобы QA соблюдали практики написания кода разработчиков (или если они более скиловые - предлагали свои). Но владение кодом должно быть общим и по большей части - у разрабов.
Это про то, что разрабы по итогу будут запускать эти тесты, чтобы понять все ли они правильно сделали. И если тест падает без очевидной причины - им надо разобраться в чем именно проблема.
Т.е. роль вполне себе актуальная.
Правда когда ее внедряют в Вотерфольных организациях это превращается в противоположность, когда QA отдельно и разрабы отдельно. Возвращаемся к вопросу о скорости фидбека.
Не верно. QA все так же нужны - их роль возвращается к их ключевой компетенции - они пишут тестовые сценарии, определяют классы эквивалентности, выполняют исследовательское тестирование, чтобы найти возможные косяки. Ревьювят тесты.
Все это добро они приносят разрабам. Разрабы это все кодируют - профит.
Конечно никто не запрещает QA писать код, если у них есть такой скил. Но это тоже должно быть правильно организовано. Все-таки разрабы больше знают про то как написать поддерживаемый код. Не каждый тестировщик этим интересуется.
Тут еще важно правильно организовать код и тесты в репе. Т.к. тесты ломаются когда меняется код. А код меняют разрабы. Значит им его и чинить. Иначе получается нездоровая динамика - сокрытие информации от разрабов, когда они не знают работает ли система, пока не запушат все и не увидят лампочку...
Спасибо за статью.
Все тесты должен писать разработчик - это ваш специалист по коду. QA только приносят ему готовые спецификации\сценарии тестов - специалисты по качеству же. Вместе, вы как команда ответственные за качество продукта.
e2e тестирование тоже выполняется разработчиками. И вы правильно заметили, про скоуп по 1 сервису. Т.к. Ваши сервисы по умолчанию должны быть Независимыми - тестируются и деплоятся отдельно от остальных. А то чего вы на самом деле боитесь - интеграция сервисов, покрывается Контрактными Тестами.
Конечно у вас должны возникнуть вопросы к правильности архитектуры ваших сервисов, их границам.
Иначе, скорее всего у вас так, - у вас появятся огромные тестовые стенды с полным поднятым окружением. Еще хуже, когда их становится больше чем у вас команд.
Рекомендую к просмотру видео Dave Farley - соавтор методологии Continuous Delivery, а конкретно про e2e тестирование и Acceptance тестирование.
Спасибо за статью. А есть причина по которой не стали смотреть на aws step functions?