d-stream

можно localhost обозвать как угодно и выпустить самоподписанный сертификат для этого чего угодно

в том числе localhost можно обозвать хоть letsencrypt.org )

Ну можно начать с анализа и прикинуть - что и где надо будет менять, если вдруг серьёзно вырастет нагрузка.
Напрашивается нечто типа некий балансировщик, который раскидывает запросы на множество web-серверов, ну а те соответственно стучатся в так или иначе горизонтально размасштабированную базу.
Вот и выходит что N контейнеров-клонов с nginx+php + M контейнеров с базой и перед ними - контейнер(ы) с балансировщиком.

Вот примерно такие абстрактные "линии разреза" в первом приближении.
Дальше уже можно смотреть в сторону полного перфекционизма когда 1 функция = 1[xN]контейнер

Тут как со сложностями у танцора - мол могут яйки мешать)

Ещё во времена когда оперативная память измерялась мегабайтами, а процессоры имели 3-значный номер и буковки sx/dx - народ вполне успешно монтировал спецэффекты в видеоматериалах. Да, это называлось "нелинейный видеомонтаж" и обработка минуты эффектов могла занять часы и даже дни. Но это работало.

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

Бинарникам - не место в нём.

Можно конечно наплодить нотификаторов для каждого задания... Но как мне кажется проще "врезать" нотификацию в сами задания шага test

ps. Успех/неуспех проще всего ловить взводя флаг в before_script/script и обрабатывать в after_script

Обычная практика: на каждой стороне прописывается список поддерживаемых/разрешенных алгоритмов и их параметров. А в момент "снюхивания" сторон между собой (как раз фаза согласования) они и выбирают тот вариант в который обе умеют.
Тем самым если задать на клиентской стороне единственный вариант - он и будет использован.

это явно не уникальная задача и поэтому первый же результат поиска "migrate svn to gitlab" приводит на сайт гитлаба

Стоит проверить что из той сети smtp откликнется и примет хотя бы HELO
А то к примеру мой провайдер уже лет 20 не пробивается и упорно блочит все исходящие на 25 порт, мотивируя это борьбой со спамом.
Ну и классику стоит проверить тоже - известен ли маршрут по которому надо идти пакетам назад? )

К тому что уже отметили, добавлю: разница между rdp-сервером и терминальным сервером примерно такая же как между компьютером и эвм - в традиционности и общеупотребительности названия)

По крайней мере в контексте вопроса - это именно два разных названия одного и того же.
Можно ещё и третий вариант: "терминальный сервер с подключением по протоколу RDP"

p.s. Без терминальных лицензий, если мне память не изменяет, подключаться по RDP к серверу можно только членам администраторской группы. Что очень и очень плохо с точки зрения безопасности

p.p.s ну и если вспоминать про 1с - у них есть понятие сервера приложений - то есть один из вариантов работы:
пользователи со своих рабочих мест тонкими клиентами подключаются к серверу/ферме серверов приложений, а уже эта ферма общается с сервером/фермой БД

Вообще раннеры - это из категории сборки, а деплой - подразумевает отправку результатов сборки на продуктовые/тестовые контура

То есть гитлаб командует раннеру/раннерам дабы они осуществили сборки, а потом отправили результаты успешной сборки на те сервера где вертится продукт

Самое простое - в commit message поместить "волшебный" текст [skip ci] либо передать опцию ci.skip гиту
Либо менять слегка схему сборки и там уже либо реагировать на условия, а в остальных случаях например не собирать (gitlab yml when/rules)

Думаю для начала стоит поглядеть в msconfig - не установлен ли лимит памяти (msconfig - загрузка - доппараметры загрузки)

Долго ковырял подобное, в итоге пришел примерно к такой реализации:
- таблица pk для обновления
- прикладная часть запрашивает диапазоны из этой таблицы и дёргает процедуру обновления с указанием диапазона
- старт идёт с короткого диапазона, если время выполнения не превышает психологический порог - на следующей итерации - берётся порция большего размера и так до порога времени выполнения

Правда это было несколько специфичным - в рамках десктопного приложения и отображением прогрессбара, но вот такой вариант адаптации размера "порции" оказался наиболее универсальным для разных серверов

1. XML_Schema (собственно то что называют xsd
2. вот п.1 и хранить (либо см. п.3)
3. для большинства яп существуют библиотеки/фреймворки которые как раз умеют:
- создать описания классов по схеме (xsd)
- сериализовывать/десериализовывать экземпляры

xslt - чуть из другой оперы - это язык описания преобразования одной схемы в другую

Категории кабеля не имеют понятности актуальности. Каждая из них имеет свой диапазон применимости. В диапазонах до 1Гбит/с - категория 5e - сверхдостаточна и оптимальна. Аналогия: фапать на кабель AWG-0000 для зарядки сотового телефона)

Домашние провайдеры не предоставляют услуг гарантированного канала - поэтому и тарифы "10Мбит" и "1гигабит" и "100500гигабит" звучат так только в рекламном булшите... в договорах звучит как "..скоростью [от нуля] до xx Гбит/с [до порта провайдера]" и в переводе на человекопонятный язык это выглядит как:
- даже скорость 0 (ноль) гигабит/с в таких тарифах юридически допустима и нормальна
- это скорость от квартиры до ближайшего коммутатора, не более...

Так что в принципе всё это скорее развод для лошков)

Классика жанра:
абоненты домового провайдера подключены гигабитом до ближайшего коммутатора, который... подключен оптикой к оптическому коммутатору ядра... тоже гигабитом... А ядро имеет пару-тройку 10 гигабитных аплинков до IX

Дальше можно прикинуть что будет когда 48 жителей одного подъезда вдруг зарядят например закачку торрентов))

Ну и да: более-менее нормальные сайты и ресурсы обязательно шейпят отдаваемый в одни руки поток... как правило не очень быстрый

Можно.
Обычно так и делают. Например в зависимости от переменной CI_COMMIT_BRANCH (ветка)

OEM лицензия windows подразумевает что производитель поставляет оборудование с windows [11] как единое целое. Естественно подразумевается что это самое изделие в виде железа и софта - работоспособно.
Соответственно остальная часть вопроса в такой постановке не имеет смысла.

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

А чего бы не попробовать?
То есть тупо нарисовать простейший .gitlab-ci.yml из одного стейджа:

image: alpine:latest 
stages:
  - Build
Build:
  stage: Build
  script:
    - echo Worked!

и потом полюбоваться на лог

По крайней мере по ссылке пишут про своего рода "продуктовые" (стартапы, opensource) linux раннеры на гугловых машинках со свежим докером