Рабочий процесс Git с тестовым сервером

Question

Я использую git для своего рабочего процесса, и у меня есть сервер удаленного тестирования. Что было бы лучшим способом сделать это.

В настоящее время я делаю изменения на своей рабочей станции, фиксирую изменения и затем отправляю их на сервер. Но это быстро привело бы ко многим маленьким коммитам. Я хочу не устанавливать тестовый сервер на моей рабочей станции.

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

Спасибо

Answer 1

Я думаю, что реальная проблема здесь в том, что вы хотите «не настраивать тестовый сервер на [вашей] рабочей станции».

Ключевая философия QAM заключается в том, что каждый хост может быть максимально похож на производственную систему, поэтому мы минимизируем объем работы, которую необходимо выполнить для перехода от разработки к тестированию и производству. 1005 *

Развертывание не является тривиальным процессом, и чем больше ваши разработчики будут иметь с ним дело, тем легче будет развернуть приложение (и его неизбежные обновления).

То есть вы действительно должны подумать: «Как близко я могу воспроизвести производственную среду на моей машине для разработки?»

Answer 2

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

Но так как вы не тестируете до после , когда вы нажимаете, я думаю, что ваши коммиты больше похожи на "упс, я сломал что-то в последний коммит". Это не хорошо и будет мешать обзору. В идеале они должны быть --amend ed для предыдущего коммита.

Код, коммит, потом тест мешает TDD. Что вы хотите сделать, так это начать с известного хорошего состояния, написать код, запустить тесты, увидеть сбой, а затем узнать, что оно было вызвано чем-то в вашем очень маленьком и простом для отладки diff.

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

Так что да, вам нужна тестовая среда на вашем компьютере разработчика. То, что запускается нажатием кнопки и быстро завершается (мы говорим минуты, вершины). Если полный набор окажется слишком медленным или громоздким, вы можете запустить только часть пакета, возможно, ту часть, которая, по вашему мнению, наиболее соответствует вашим изменениям, и затем позволить тестовому серверу запустить полный пакет после нажатия. Это хороший компромисс между эффективностью теста и тщательностью.

Если по какой-то причине вы не можете запустить тестовую среду на своем компьютере разработчика, вы можете работать в своей собственной ветке и отправить ее для тестирования. Тогда, если это не сработает, вы можете --amend исправить. Как только вы закончите с вашей функцией, вы можете объединить ваши изменения в мастер. Это исключает коммиты «упс, я сломал» и удерживает вас от взлома мастера для всех остальных, в то же время делая небольшие коммиты, которые легко просматривать.

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

Answer 3

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

То, что я в итоге сделал, что меня не совсем устраивает, - это создание тестового экземпляра сценария обработки на рабочем сервере и частое его развертывание во время разработки.

Раньше мы использовали Subversion, и я установил Darcs поверх этого, что хорошо работало. Редактирование, фиксация в Darcs, загрузка в тестирование, повторное полоскание, фиксация в SVN, загрузка в производство.

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

#!/bin/sh

set -e

branch=${1-dev}

# Temporarily switch to a different branch so that pushing is safe
ssh server 'cd project &&
        { git branch -d trash 2>/dev/null || true
            git checkout -b trash; }'

git push server:project "$branch"

# Switch to the newly pushed
ssh server "cd project && git checkout $branch"

С Darcs я смог внести изменения на тестовом сервере и вытащить их обратно, но с Git мне кажется, что мне нужно будет воздержаться от этого.

Answer 4

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