Какое самое умное использование исходного репозитория вы когда-либо видели?

Это на самом деле связано с моим предыдущим вопросом, когда один из ответов заставил меня задуматься о том, как люди используют scm/repository по-разному для разработки.

Источник

3 ответа

Решение

Предварительно протестированные коммиты

До (TeamCity, менеджер сборки):

Идея проста: система сборки выступает в качестве барьера между входом в ваш коммит, и только после того, как система сборки определит, что ваш коммит не сломал вещи, он позволяет ввести коммит в управление версиями, где другие разработчики будут синхронизировать и интегрировать эти изменения в свои локальные рабочие копии

После (с использованием DVCS, такого как Git, это исходный репозиторий):

Мой рабочий процесс с Hudson для предварительно протестированных коммитов включает три отдельных репозитория Git:

  • мой локальный репо (местный),
  • канонический / центральный репо (происхождение)
  • и мой "читаемый мир" (внутри брандмауэра) репо (публичный).

Для предварительно протестированных коммитов я использую постоянно меняющуюся ветку "pu" (потенциальные обновления) в читаемом мире репо.
Внутри Хадсона я создал задание, которое опрашивает общедоступный репозиторий (public) на предмет изменений в ветке "pu" и запускает сборки, когда запускаются обновления.

мой рабочий процесс для принятия изменения от начала до происхождения:

* hack, hack, hack
* commit to local/topic
* git pup public
* Hudson polls public/pu
* Hudson runs potential-updates job
* Tests fail?
      o Yes: Rework commit, try again
      o No: Continue
* Rebase onto local/master
* Push to origin/master

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

(Вариация) Private Build (Дэвид Гагеот, Альгодеал)

Принцип тот же, что и выше, но сборка выполняется на той же рабочей станции, что и для разработки, но на клонированном репо:

Как не использовать CI-сервер в долгосрочной перспективе и не страдать от растущего времени, потраченного на локальные сборки?

С мерзавцем это кусок пирога.
Сначала мы "клонируем" рабочий каталог в другую папку. Git делает копию очень быстро.
В следующий раз нам не нужно клонировать. Просто скажи мне, что надо получить дельты. Чистый результат: мгновенное клонирование. Впечатляет.

Как насчет последовательности?
Делать просто git pull 'из рабочего каталога, используя дайджесты дельты, поймет, что изменения уже внесены в общий репозиторий.
Нечего делать. Впечатляет снова.

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

Теперь у нас есть частная сборка без обслуживания, без дополнительной установки, не зависящая от IDE, которая запускается с одной командной строкой. Нет больше неработающей сборки в общем хранилище. Мы можем перезапустить наш CI сервер.

Да. Вы хорошо слышали. Мы только что создали CI без сервера. Каждая дополнительная функция реального CI-сервера - это для меня шум.

#!/bin/bash
if [ 0 -eq `git remote -v | grep -c push` ]; then
  REMOTE_REPO=`git remote -v | sed 's/origin//'`
else
  REMOTE_REPO=`git remote -v | grep "(push)" | sed 's/origin//' | sed 's/(push)//'`
fi

if [ ! -z "$1" ]; then
  git add .
  git commit -a -m "$1"
fi

git pull

if [ ! -d ".privatebuild" ]; then
  git clone . .privatebuild
fi

cd .privatebuild
git clean -df
git pull

if [ -e "pom.xml" ]; then
  mvn clean install

  if [ $? -eq 0 ]; then
    echo "Publishing to: $REMOTE_REPO"
    git push $REMOTE_REPO master
  else
    echo "Unable to build"
    exit $?
  fi
fi

Dmitry Tashkinov, у которого есть интересный вопрос о DVCS и CI, спрашивает:

Я не понимаю, как "Мы ​​только что создали CI без сервера" в соответствии с состоянием Мартина Фаулера:
"После того, как я сделал свою собственную сборку должным образом синхронизированной рабочей копии, я наконец смогу зафиксировать свои изменения в основной строке, которая затем обновит репозиторий. Однако мой коммит не заканчивает мою работу. В этот момент мы строим снова, но это время на машине интеграции, основанной на основном коде. Только когда эта сборка завершится успешно, мы сможем сказать, что мои изменения сделаны. Всегда есть вероятность, что я что-то пропустил на своей машине, и хранилище не было должным образом обновлено ".
Вы игнорируете или сгибаете это?

@Dmitry: я не игнорирую и не сгибаю процесс, описанный Мартином Фаулером в его записи ContinuousIntegration.
Но вы должны понимать, что DVCS добавляет публикацию как ортогональное измерение к ветвлению.
CI без сервера, описанный Дэвидом, является просто реализацией общего процесса CI, детально описанного Мартином: вместо того, чтобы иметь CI-сервер, вы перемещаетесь в локальную копию, где выполняется локальный CI, а затем вы отправляете "действительный" код в центральное хранилище.

@VonC, но идея состояла в том, чтобы запустить CI NOT локально, чтобы не пропустить что-то при переходе между машинами.
Когда вы используете так называемый локальный CI, он может пройти все тесты только потому, что он локальный, но позже выйдет из строя на другом компьютере.
Так это интеграция? Я вообще не критикую здесь, вопрос сложный для меня, и я пытаюсь понять.

@Dmitry: "Так это интеграция"?
Это один уровень интеграции, который может помочь избавиться от всех основных проверок (таких как проблема с форматированием, стиль кода, обнаружение базового статического анализа, ...)
Поскольку у вас есть этот механизм публикации, вы можете при необходимости связать этот вид CI с другим сервером CI. Этот сервер, в свою очередь, может автоматически выдвигать (если это все еще ускоренная перемотка вперед) к "центральному" репо.

Дэвид Гаге не нуждался в этом дополнительном уровне, поскольку уже достиг цели в плане архитектуры развертывания (ПК-> ПК) и нуждался только в базовом уровне CI.
Это не мешает ему настроить более полный сервер системной интеграции для более полного тестирования.

Источник

Мое любимое? Неизданный инструмент, который использовал Bazaar (DSCM с очень хорошо продуманной явной обработкой переименования) для отслеживания данных с древовидной структурой, представляя хранилище данных как структуру каталогов.

Это позволило разветвить и объединить XML-документ со всеми преимуществами (обнаружение и разрешение конфликтов, рабочий процесс проверки и, конечно, регистрация изменений и т. Д.), Которые стали простыми благодаря современному распределенному управлению источниками. Разделение компонентов документа и его метаданных на их собственные файлы позволило избежать проблем, связанных с близостью, и создать ложные конфликты, а также разрешить всю работу, которую команда Bazaar вложила в деревья файловой системы управления версиями, для работы с данными древовидной структуры других типов.

Источник

Определенно, Polarion Track & Wiki...

Вся база данных по отслеживанию ошибок и вики хранится в Subversion, чтобы иметь возможность вести полную историю изменений.

http://www.polarion.com/products/trackwiki/features.php

Источник
Другие вопросы по тегам