Сначала немного справочной информации: в настоящее время мы находимся в процессе миграции большого репозитория git с Bitbucket на Azure Devops. Были некоторые проблемы, потому что репозиторий имеет историю, полную двоичных блобов, которые, оглядываясь назад, были совершенно ненужными.
После предварительного опробования bfg-repo-cleaner мы, наконец, закончили использовать git filter-repo и успешно сократили размер репо с нескольких гигабайт до примерно 400 мегабайт (в зависимости от того, что вы считаете). Мы также переписали некоторые названия тегов.
Наш процесс заключался в том, чтобы сначала создать свежий клон из битбакета, а затем запустить сценарий оболочки, который сжимает репо. После этого мы отправили репо в новый пустой репозиторий, созданный в Azure Devops.
Все прошло намного проще, чем мы ожидали. git filter-repo работал быстро, и весь процесс занял не более часа.
Прежде чем мы почувствовали себя в безопасности, выполняя перемещение (и заставляя всех наших разработчиков замораживать репо на некоторое время), мы выполнили пару тестовых запусков, чтобы убедиться, что мы не потеряли никаких данных, и конвейер Azure Devops может так же хорошо построить наш код. как раньше делал Бамбук.
Мы успешно создали yml pipleline, на выполнение которого в общей сложности ушло примерно 4 минуты. Чувствуя уверенность в том, что мы решили все наши проблемы, мы приступили к выполнению всего процесса по-настоящему. Все прошло гладко, и мы быстро переместили всех наших разработчиков в новый репозиторий.
Проблема. Затем мы заметили, что создание нашего нового конвейера заняло намного больше времени, чем наши предыдущие тесты. Покопавшись в журналах, мы обнаружили, что это как-то связано с загрузкой объектов.
Новое репо (оформление заказа занимает 8 минут)
удаленный: найдено 39837 объектов для отправки. (1316 мс)
Прием объектов: 100% (39837/39837), 809.66 МиБ | 1,69 Мбайт / с, готово.
Тестовое репо (оформление заказа занимает 31 секунда)
удаленный: найдено 11772 объекта для отправки. (358 мс)
Прием объектов: 100% (11772/11772), 80,17 Мбайт | 8,75 Мбайт / с, готово.
Я думаю, уместно упомянуть, что мы используем --depth = 1 во время оформления заказа. В нашем тестовом конвейере это резко сократило время оформления заказа.
Сейчас мы находимся в точке, где мы счастливы, что все работает, и можем попрощаться с дорогостоящим VPS, на котором размещаются как bitbucket, так и bamboo, но разочарованы более длительным временем сборки, к которому мы привыкли.
Я подозреваю, что наши файлы пакетов почему-то недостаточно оптимизированы, поэтому вам нужно загрузить их больше, чтобы клонировать репо. Я говорю клонировать, потому что конвейер, кажется, запускает новое репо, добавляет удаленный объект и выполняет выборку. Когда я делаю настоящий клон на своей локальной машине разработчика, это занимает всего 5 минут (включая передачу через Интернет и разрешение дельт). Я нахожу это очень странным.
Любая помощь будет принята с благодарностью. Спасибо,
Пит Экхарт
