Комментарии 5
В Community Edition GitLab в актуальной версии уже внесены настройки, запрещающие по умолчанию аппрувить свои изменения. Это работает даже в случаях, когда разработчик добавляет коммит в чужую ветку — он всё равно не сможет влить в неё изменения без аппрува.
В Community Edition GitLab аппрувы не доступны - кнопка там есть но она ни ни что не влияет, даже если не проставить аппрувы мерж можно будет выполнить всё равно. Настоящие аппрувы доступны начиная с Premium
Или вы нашли какой-то способ включить аппрувы в Community Edition GitLab?
Привет, спасибо за комментарий, в статье действительно была оговорка, речь шла про версии кроме Gitlab CE (Premium, Ultimate). Поправили. Для Gitlab CE можно попробовать использовать механизм CODEOWNERS (не доступен для СЕ) - можно сделать самому как в примере одного из докладов Алексея https://rutube.ru/video/d87cc964a9b0f91c4f38b9bebf5c9387/?t=700&r=plwd
В статье вы подробно описываете подход к построению пайплайна для разных окружений и автоматизации всего цикла разработки и доставки. Однако нередко узким местом подобных систем становятся обновления баз данных и миграции схем при релизах, особенно если требуется zero-downtime.
Как вы гарантируете согласованность данных, когда код одной версии сервиса может временно работать с уже изменённой или ещё не до конца мигрированной схемой? И как при этом выстраивается процесс отката (rollback) при обнаружении критической ошибки, учитывая, что состояние базы данных зачастую нельзя «просто вернуть» к предыдущему состоянию без риска потери данных?
Приветствую, достаточно комплексный вопрос, тут наверно потребуется целая статья отдельная. Если кратко, то набор разных инструментов: фича-тоглы, канарейки, и т.д. есть много вариантов построения.
Про БД не совсем понял запроса? пока идет разработка, это дело обкатывается не на продовых данных, перед выкаткой на прод можно обкатать на полном зеркале прода, протестировать вдоль и поперек. Вообще сама концепция микросервисной архиектуры подразумевает, что сами микросервисы атомарны и независимы, изменения одного сервиса не должны корраптить остальные
Вы упомянули фича-тоглы и канареечные выкатки, но не объяснили, как решаете задачу согласованности данных в БД при поэтапном внедрении миграций.
Предположим, у вас есть несколько микросервисов, которые используют одни и те же таблицы, и вы вносите несовместимые изменения в схему (добавляете или меняете поля).
Как вы гарантируете, что часть сервиса со старой логикой корректно работает с новой схемой, пока не завершится канареечная выкатка? И что будет при откате, если новая версия уже успела создать/изменить записи в недопустимом для старого кода формате?
Безопасность CI/CD — базовая гигиена и реализация в разработке облака MWS