Pull to refresh

Comments 6

Зачем делать отдельный Docker Registry, когда GitLab давно уже поддерживает свой встроенный? Там нет лишних телодвижений или каких-то проблем.

Согласен, можно использовать и встроенный.

А кто как решает проблему синхронизации кода в базе и в разных ветках?

Какая у вас проблема?


При изменениях кода "наживую" нужно сначала настроить альтернативу — CI/CD, а потом запретить обновление другими способами.

Есть такая статья Разработка в InterSystems Caché в вашей любимой IDE. Там предлагается работать только с файлами, а при необходимости компилировать весь проект. По сути при переключении в другую ветку тоже надо компилировать весь проект. Для большого проекта это может занимать продолжительное время. Также будут оставаться классы созданные в другой ветке, но отсутствующие в текущей выбранной. Еще возможны проблемы при изменении структуры таблицы, например убрали старые поля и сместили новые на их место. Есть ли отработанные схемы для работы с системой контроля версий?

В предыдущей статье была предложена система коллбэков для CI. В данном проекте предлагается следующая схема инкрементальной компиляции:


  1. Выполняются постоянные коллбэки и одноразовые коллбэки прекомпиляции.
  2. Строится Diff между текущим коммитом окружения и целевым коммитом.
  3. Загружаются добавленные/обновлённые файлы.
  4. Список удалённых файлов должен быть обработан пользователем (каждый элемент списка должен быть транслирован из имени файла во внутреннее имя и обработан).
  5. Выполняются постоянные коллбэки и одноразовые коллбэки посткомпиляции.
  6. Регистрируется текущий коммит окружения, названия одноразовых коллбэков.

Эта общая схема может быть расширена под конкретное приложение.

Sign up to leave a comment.