Mercurial: синхронизировать 2 ветки, но с определенными постоянными различиями?

Question

Я веб-разработчик, работающий самостоятельно с использованием django, и я пытаюсь понять, как лучше развернуть сайты с помощью Mercurial. Я хотел бы иметь один репозиторий, который мог бы использовать как для производства, так и для разработки. Всегда будут некоторые различия между производством / разработкой (например, они могут использовать разные базы данных, при разработке всегда будет включена отладка), но в целом они будут синхронизированы. Я также хотел бы иметь возможность вносить изменения непосредственно на рабочем сервере (приведение в порядок html или css, простые исправления ошибок и т. Д.).

Рабочий процесс, который я собираюсь использовать для этого, выглядит следующим образом:

• Создание 2 веток, prod и dev (все настройки изначально настроены на производственные настройки)
• Измените settings.py и несколько других вещей в ветке dev. Так что теперь у меня есть 2 головы, и теперь в хранилище всегда будет 2 головы.
• (на компьютере разработчика) Внесите изменения в dev, затем используйте «hg трансплантат» для копирования соответствующих наборов изменений в производство.
• отправка в главный репозиторий
• (на рабочем сервере) Извлечение из главного репозитория, обновление до головки продукта

Примечание: вы также можете вносить изменения прямо в продукт, если вы пересаживаете изменения в dev.

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

Answer 1

Я бы, вероятно, использовал Mercurial Queues для чего-то подобного. Сохраните основной репозиторий в качестве версии для разработки и установите патч for-production, который вносит все необходимые изменения для производства.

Answer 2

Я решил это с локальными настройками.

1. Добавить в settings.py: try: from local_settings import * except ImportError: pass

2. touch local_settings.py

3. Добавьте ^local_settings.py$ к вашему .hgignore

У каждого развертывания, которое я делаю, есть свои собственные локальные настройки (обычно разные вещи БД и разные адреса электронной почты источника).

PS: читать «минимизированные версии части JavaScript» только позже. Для этого я бы предложил перехват после обновления и настройку конфигурации (например, JS_EXTENSION).

Пример (от макушки головы! Не проверял, адаптируйте по необходимости):

1. Поместите JS_EXTENSION = '.raw.js' в ваш файл settings.py;
2. Поместите JS_EXTENSION = '.mini.js' в файл local_settings.py на рабочем сервере;
3. Изменить включение JS с: <script type="text/javascript" src="blabla.js"></script> Для того, чтобы: <script type="text/javascript" src="blabla{{JS_EXTENSION}}"></script>
4. Создание перехвата после обновления, который ищет *.raw.js и генерирует .mini.js (минимизированные версии raw);
5. Добавьте .mini.js$ к вашему .hgignore

Answer 3

Вот два возможных решения: одно с использованием Mercurial, а другое без Mercurial:

1. Используйте имя хоста для переключения между prod и devel. У нас есть одна проверка в верхней части нашего файла настроек, которая просматривает переменную среды SERVER_NAME. Если это www.production.com, это prod DB, в противном случае он выбирает указанную или стандартную базу данных dev / test / stage.
2. Используя Mercurial, просто получите клона dev и клона prod, внесите все изменения в dev и, во время развертывания, переключитесь с dev на prod. После вытягивания у вас будет 2 головы в выд, отличающихся от одного общего предка (последнее развертывание). Одна голова будет иметь один набор изменений, содержащий только различия между развертываниями dev и prod, а другая будет иметь всю новую работу. Объедините их в клоне prod, конечно же, выбрав изменения в prod при конфликте, и вы получите развертываемую настройку, и готовы выполнять больше работы над «dev». Нет необходимости разветвлять, пересаживать или использовать очереди. До тех пор, пока вы никогда не вытянете этот набор изменений с настройками prod в 'dev', он всегда будет нуждаться в слиянии после извлечения из dev, и если это всего лишь несколько строк, делать не нужно.

Answer 4

Я фактически делаю это, используя именованные ветви и прямое слияние вместо пересадки (что более надежно, IMO). Обычно это работает, хотя иногда (когда вы редактировали разные файлы в другой ветке), вам нужно будет обратить внимание, чтобы не удалять различия при объединении.

Так что это прекрасно работает, если вы не сильно меняете различные файлы.

Answer 5

Возможно, попробуйте что-то вроде этого: (Я просто думал об этой проблеме, в моем случае это база данных sqlite)

• Добавьте settings.py в .hgignore, чтобы он не попадал в хранилище.
• Возьмите файлы settings.py из двух отдельных ветвей и переместите их в два отдельных файла, settings-prod.py и settings-dev.py
• Создайте сценарий развертывания, который копирует соответствующий файл settings-X в settings.py, чтобы вы могли развернуть его любым способом.

Если у вас есть пара дополнительных файлов, сделайте то же самое для них. Если у вас много файлов, но все они находятся в одном и том же каталоге, вы можете просто создать пару каталогов: production и development, а затем скопировать или вставить символическую ссылку в соответствующий каталог в deploy каталог.

Если бы вы сделали что-то подобное, вы могли бы обойтись без необходимости ветвления вашего хранилища.