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

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

Примере

[...]
path_to_something = "this/is/different"

use_something(path_to_something)

[...]

do_thing_A() # Only in environment A.

[...]

do_thing_B() # Only in environment B.

[...]

Пропущенные части [...] идентичны в обеих версиях, и когда я вношу в них изменения, мне приходится либо копировать и вставлять каждую измененную строку, либо, если изменения значительны, копировать все это и вручную изменять Части A и B.

Некоторые идеи возможных решений, которые я придумал:

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

  2. Это вариант использования gitattributes?

  3. Разложите весь код, идентичный между версиями, в отдельные файлы, чтобы файлы, содержащие гетерогенный код, вообще не нуждались в изменении и, следовательно, не нуждались в управлении версиями как таковых.

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

Оглядываясь вокруг, я нашел вопрос с аналогичной предпосылкой поддержки разных версий кода, которые делают то же самое:

Как правильно поддерживать проект, который соответствует двум версиям платформы?

Предлагаемые решения на этот вопрос:

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

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

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

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

0
Holistic IT 20 Ноя 2017 в 15:41

1 ответ

Лучший ответ

Независимость от языка и SCM

  1. Используйте один (два, три) общих класса (ов), но разные интерфейсы (интерфейс для каждой среды).
  2. Перенести все специфичные для env из жесткого кода во внешнюю конфигурацию, хранящуюся отдельно

SCM-агностик

Отдельные задачи , то есть:

  • Получите чистое общее ядро
  • Получайте изменения в верхнем ядре для каждой среды
  • Переместите его в ветки $ENVS+1 в любом SCM (Core + ... + EnvN)

Измененный рабочий процесс стал

  • Зафиксируйте общие изменения в Core
  • Слияние Core с каждой Env-веткой
  • Протестируйте ветки env, при необходимости исправьте изменения, специфичные для env

Личное и личное, предпочтительное для меня и моих привычек

Вариант решения ветвь-дерево

Чисто Mercurial, потому что мне лень поддерживать ветки, специфичные для Env

Mercurial, одна ветвь + MQ-очередь с набором патчей (один mq-патч на Env, может быть «набор очередей / очереди на Env /, один патч на очередь»)

Общий код, хранящийся в неизменяемых наборах изменений, любые изменения, которые преобразуют простое ядро ​​в продукты, специфичные для среды, хранятся в патчах и применяются по запросу (и редактируются, когда | при необходимости).

  • Небольшие преимущества перед ветвлением - одна ветвь, отсутствие слияний, более чистая история
  • Недостаток - чистый Mercurial, ныне модный Git (git-boys плачут)
0
Lazy Badger 20 Ноя 2017 в 15:32