Использование репозитория hg в качестве веб-сайта

Это отчасти связано с моим контрольным вопросом, который здесь. Использовать репозиторий hg / mercurial для живого веб-сайта - плохая идея? Если да, то почему?

Кроме того, у нас есть установки для разработки, тестирования и производства нашего веб-сайта, такие как dev.example.com, test.example.com и www.example.com. Если использовать репозиторий для живого / производственного веб-сайта - плохая идея, можно ли использовать репозиторий hg для сайта разработки и тестирования?

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

Как лучше всего этого добиться?

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

/root [main repository containing core files and subrepositories]
    /modules [modules subrepository]
    /sites/global [subrepository for global .css and .php files]
    /sites/site1 [site1 subrepository]
    ...
    /sites/siteN [siteN subrepository]

Разработчики программного обеспечения работали бы в репозиториях root, modules и sites/global. Менее техничные люди (веб-дизайнеры) будут работать только в site1 ... siteN подрепозиториях.


web mercurial tortoisehg
person tex    schedule 02.03.2010    source источник

Ответы (4)


arrow_upward
4
arrow_downward

Да, это плохая идея.

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

Однако на самом деле я обращаюсь к этой «концепции» (управление версиями как развертывание) с помощью написанного мною инструмента (несколько других компаний также обращаются к этой теме, так что вы увидите ее подробнее). Моя предназначена для SVN (на данный момент), поэтому она не особенно актуальна; Я упоминаю об этом только для того, чтобы показать, что я уже рассматривал это ранее (но не в репозитории; рабочая копия, в этом сценарии ответ тот же: лучше иметь не версионированные «бесплатные» в качестве каталога веб-сайта, и автоматизировать (посредством действий пользователя) копирование «версионных» данных в этот каталог).

person Noon Silk    schedule 02.03.2010
comment
Я планировал разрешить большинству пользователей push на dev сайт, но разрешить только нескольким администраторам переходить на test и live сайты. Это вообще меняет ваш ответ? - person tex; 02.03.2010
comment
@Tex: Нет, не совсем. Подумайте вот о чем: вы фактически делаете систему управления версиями более рискованной в использовании. Люди должны думать: «Хорошо, это не только готово для фиксации, но и готово ли оно для развертывания разработчика?» Это актуально в местах, где может тестировать более одного «разработчика», и в других подобных сценариях. Я бы придерживался мысли, что вы хотите, чтобы ваш исходный элемент управления был «простым» в использовании, и что развертывание - это «отдельное» действие (возможно, я здесь предвзято, потому что это то, над чем я специально работаю). Мои взгляды, FWIW. - person Noon Silk; 02.03.2010
comment
Спасибо, что обсудили это со мной. Я рассмотрел некоторые из этих моментов. Я также рассмотрел возможность создания песочницы / сайта тестирования для каждого разработчика на нашем веб-сервере (опять же, каждый сайт является репозиторием hg). Затем я мог бы разрешить каждому разработчику / дизайнеру push заходить на его сайт-песочницу для тестирования и разрешить только администраторам нажимать на dev, test и live. Мне сложно придумать рабочий процесс, которому могут легко следовать нетехнические парни. - person tex; 02.03.2010
comment
@Tex: Нет проблем. Действительно, в своей системе я работаю над аналогичным подходом (вы развертываете изменения последовательно: фиксация, сборка, развертывание (туда, где вы хотите, обычно тестируйте), затем тест обновляется до промежуточного уровня, а этап тестирования обновляется до реального времени. Другие сложности на подходе. Я не использую HG, поэтому я не совсем знаю, отличается ли «толчок» от «фиксации» (я думаю, что это может быть, но я не уверен). Все, что я » Я хочу быть уверен в следующем: 1) commit прост и не требует работы, 2) развертывание (обычно) выполняется отдельно и вручную (настраивается на автоматическое или ручное). 3) Случайное развертывание - person Noon Silk; 02.03.2010
comment
... можно легко поменять местами. Если предположить, что ваша система настроена таким образом, мне это кажется разумным. Но я не уверен, насколько легко / возможно это сделать в HG. И, конечно же, с SVN вы не захотите указывать веб-сайт на репозиторий, потому что там много странных файлов. С HG это может быть не так. - person Noon Silk; 02.03.2010

arrow_upward
4
arrow_downward

Многие люди хранят свои сайты в репозиториях, и пока у вас нет людей, редактирующих живые сайты, все в порядке. Создайте область подготовки / разработки, где ваши люди, не занимающиеся контролем версий, вносят свои изменения, а затем попросите кого-нибудь, кто более дружелюбен к RCS, периодически выполнять цикл фиксация-вытягивание-слияние-проталкивание.

Пока это сознательное действие оценивающего человека, выполняющего push staging-area -> production-repo, все в порядке. Вы даже можете добавить ловушку в производственный клон, который автоматически выполняет «hg update» рабочего каталога в этом производственном клоне, так что «push» - это все, что требуется для развертывания.

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

person Ry4an Brase    schedule 02.03.2010

arrow_upward
2
arrow_downward

лично я (я команда из одного человека), и мне очень нравится идея использовать src control в качестве живого веб-сайта. тем более с hg, затем с svn.

как я вижу, вы можете загрузить весь сайт (добавить / удалить файлы) с помощью одного cmd, намного проще, чем ftp / ssh, это, удалить это и т. д.

если вы используете apache (и, вероятно, iis), вы можете создать простой файл .htaccess, который будет блокировать все файлы .hg (или .svn, если вы используете svn)

Моя предпочтительная структура - сайт разработки находится на локальном компьютере, работающем непосредственно из репозитория (здесь действительно не требуется безопасность, делайте то, что вам нравится, фиксируйте по мере необходимости)

промежуточная / тестовая машина - это отдельный ящик или виртуальная машина, на которой запущена последняя копия живой базы данных (у меня есть сценарий для отправки зафиксированных изменений на промежуточный сервер и запуска тестов)

живая машина (открыть ssh-соединение, отправить изменения на живой сервер, снова протестировать, все может быть достаточно легко написано сценарием, например, Google)

из-за природы push / pull hg это означает, что вы можете фиксировать изменения и тестировать, не опасаясь отправки сломанной сборки на работающий веб-сайт. как вы говорите в своих комментариях, только определенные люди должны иметь разрешение на размещение версии на действующем сайте. (в случае неудачи вы легко сможете вернуться к предыдущей версии с помощью элемента управления src)

person bumperbox    schedule 12.04.2010

arrow_upward
0
arrow_downward

Почему бы репо не быть активным веб-сервером (в любом случае для среды разработки или тестирования / контроля качества)?

Вот что я пытаюсь реализовать:

  • У разработчиков есть локальные тестовые среды, в которых они могут создавать и тестировать свой код.
  • Разработчики создают клон среды разработки на своей локальной машине разработки.
  • Разработчики фиксируют свои локальные репо так часто, как хотят.
  • Когда часть работы выполнена и протестирована, разработчик отправляет рабочие наборы изменений в репозиторий разработчика.

Изменения будут объединены и протестированы на Dev, затем отправлены в Test / QA и так далее.

Кстати, мы используем Mercurial. Я считаю, что эта модель будет работать только при использовании инструмента управления распределенным исходным кодом.

person dhunter65    schedule 10.12.2010