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

Question

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

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

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

Благодаря

Answer 1

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

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

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

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

Answer 2

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

Answer 3

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

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

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

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

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

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

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

Answer 4

У меня возникла ситуация, когда я разрабатываю инструмент для обработки конфиденциальных данных. Это означает, что моя среда разработки имеет только статические тесты, и мне нужно развернуть изолированный сервер, который не имеет доступа к регулярному выпуску 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, она смотрит на меня, как мне нужно будет воздержаться от этого.