Контроль версий для отчетов (git)

Question

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

У меня есть две надежды на эти отчеты:

1), чтобы иметь возможность воспроизвести любой отчет на более поздний срок. 2) возможность просмотра структурных изменений, внесенных в отчет с течением времени.

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

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

Я могу придумать несколько разных способов сделать это: создать ветку для каждого отчета, но только объединить структурные изменения обратно на мастера; клонировать мастера в подпапку для нового отчета, вносить туда изменения, отталкивать структурные изменения; и т. д. Но я действительно даже не знаю достаточно, чтобы отделять безумные идеи от правдоподобных, а тем более хороших. Дайте мне знать, что вы думаете. Благодарю.

Answer 1

Я бы лично пойти для первого предложения:

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

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

Answer 2

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

Если вы можете предвидеть, какие поля меняются каждый раз, я бы сказал, что вы делаете общий отчет, который запрашивает эти данные каждый раз, когда выполняется отчет. Вы должны быть в состоянии сделать это практически в любом программном обеспечении для отчетности. Сам отчет можно отследить в git, и вам не придется беспокоиться о наличии 50 000 филиалов в вашем репозитории.

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

Если вы запустите этот отчет много и заинтересованы в отслеживании различных наборов , я бы предложил другой подход. Я не знаю, что генерирует ваш отчет, но скажем, что это PDF. Я бы сделал структуру каталогов где-то, и вы можете сохранить каждый прогон в results/year/month/date.pdf. Таким образом, у вас будет запись данных, перенесенных 5 мая 2010 года (или с 5 мая 2010 года в качестве параметра).

Редактировать: Вы можете рассматривать теги вместо ветвей для тех вещей, которые вы не можете объединить в один отчет. Если у вас есть версия, по-вашему, вам нужен быстрый доступ, отметьте ее. Каждый раз, когда вам нужно вернуться к нему, просто проверьте тег и запустите отчет.

Answer 3

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

Итак, один .sas-файл с одним крупным макросом в нем, в зависимости от параметров, которые вы используете для вызова макроса, он может воспроизводить все нужные вам отчеты.

Это имеет смысл для вас? Если это не дает мне знать, и я мог бы привести несколько примеров SAS Macro, чтобы вы начали, если вы не знакомы с ним.