До 40 релизов в день в Enterprise: наша сool story

[sojey80135]

не понял если у вас параллельно 2 фичи разрабатываются из точки А и потом тестируется на одной тестовой машине последовательно, то
1я команда раскатывает свой Х, всё хорошо
2я команда поверх выкатывает Y раскатывает скрипты миграции на базу и возникает конфликт что скрипты миграции не подразумевали изменения в X

как это работает?

[Digital_Platform]

Здравствуйте. Вы описали типовую проблему, с которой каждый день сталкиваются разработчики, которые работают над общим кодом. В описанном вами примере все отработает именно так как вы и описали: 2-я команда получит ошибку и ей нужно будет подтянуть изменения 1-й, т.е. их скрипты изменения БД Y должны будут поменяться так, чтобы учитывать X.

Стоит отдельно сказать, что код сервиса и скрипты изменения БД в нашем случае это 2 различных репозитория.

[hedera]

Смею предположить, что разработчики между собой общаются, команда 1 и 2 договариваются об взаимоучете изменений.

[sysilya]

Отлично! Очень интересная статья, можно добавить больше технических деталей)

[Digital_Platform]

Спасибо.

Планируем углубляться в технику по отдельным направлениям с следующих статьях. О чем вам хотелось бы узнать подробнее?

[voodoo144]

В чем проблема использовать CODEOWNERS файл для разграничения доступа на уровне папок?

Любые изменения в такой папке быдут требовать аппоува от владельца папки/группы владельцев.

[Keeperovod]

В кодовой базе на 100Гб? Кажется работать будет слишком медленно

[voodoo144]

На такого размера кодовой базе все будет работать медленно. Мне даже кажется что sparse checkout не поможет.

Но CODEOWNERS файл это встроенная фича GitHub, по идее должно работать быстро.

[Keeperovod]

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

На самом деле, проблема разграничения доступов вообще была последней, о которой думали на старте, не говоря о том, что в 2015-м этой фичи не было.

Два основных кошмара — отслеживание зависимостей на уровне файловой системы. Многие до сих пор это любят, как показывает общение с коллегами. Заставить разработчика работать через пакеты в одном репозитории очень тяжелая задача.

Вторая проблема — корректное отслеживание изменений, в каком компоненте что поменялось и с какой версией ее надо пересобрать и т.п. На маленьких отдельных репозиториях это делать было гораздо проще. Единая версия на репозиторий с несколькими компонентами это вообще жесткий антипаттерн.

На практике это оказалось удобно, далее шла эволюция.

[voodoo144]

GitHub Enterprise - версия хоститься у вас имеет все плюшки обычного гитхаба, но с упором на Энтерпрайз клиентов.

[Keeperovod]

Замечание принято, спасибо. Но сути дела не меняет, т.к. доступы это доля малая от комплекса проблем, которые надо решить.

[HavenDV]

Вопрос не в тему — У вас есть Bug Bounty программа?
В прошлом году находил баг, который позволял обменивать валюту так, что зачисление происходило несколько раз подряд.

[Digital_Platform]

Вопрос действительно не по теме статьи. Написал Вам в личку.