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

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

Теперь, как программист, моя первая интуитивная реакция заключается в том, что никто не должен вызывать "svn up" и "svn ci", кроме человека. В недавнем случае объединенные версии группы файлов .rNNNN сломали инструменты, с чего и началось это обсуждение.

Теперь парень, разрабатывающий инструменты, фактически признал, что использует SVN для синхронизации файлов и что он мог бы заменить все это монтированием NFS. Он даже сказал, что завернет "svn diff" в "make diff", потому что это казалось лучше, чем все мы знали, как работает SVN.

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

Вот мой список на данный момент:

  1. На самом деле мы не версионируем эти данные, поэтому они не должны попадать в svn.
  2. Мы сказали, что его можно заменить монтированием NFS, так почему бы нам не сделать это.
  3. Доморощенные инструменты теперь обертывают SVN, а в программном обеспечении всегда будут ошибки, поэтому наши версии SVN теперь будут иметь беспорядок, сделанный из версии, когда мы столкнемся с ошибками.

... пожалуйста, обсудите/помогите мне сделать это или скажите, почему вы не согласны!


workflow svn sysadmin cfengine
person Martin    schedule 17.05.2009    source источник
comment
Возможно, я должен добавить, что эти инструменты работают в двух общих рабочих копиях наших данных (prod/test). Когда они терпят неудачу, мы получаем разные текстовые значения, которые должны быть уникальными, и синхронизация файлов из теста в продукт завершается ошибкой.   -  person Martin    schedule 18.05.2009

Ответы (4)


arrow_upward
4
arrow_downward

SVN — неплохой инструмент для синхронизации файлов на машинах! Если я хочу, чтобы на нескольких машинах была одна и та же версия файла, то наличие на них Subversion и возможность проверить их — это находка. Да, вы можете использовать такие инструменты, как rsync или иметь монтирование NFS, чтобы поддерживать их в актуальном состоянии, но, по крайней мере, subversion позволяет вам хранить все версии и выполнять откат/вперед, когда вы хотите.

Однако я скажу одну вещь: автоматическое обновление машин из магистрали, вероятно, плохая идея, когда эти файлы могут сломать вашу систему, они должны обновляться из тега. Таким образом, вы можете проверять и поддерживать историю изменений, ПРОВЕРЯТЬ их, а затем применять тег, который будет синхронизировать файлы на других машинах при их обновлении.

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

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

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

person Neil Trodden    schedule 17.05.2009
comment
У меня проблема в том, что инструменты, которые у нас есть, проверяют только половину файлов из-за конфликтов из-за обновлений. Тогда состояние мира нарушено, как вы говорите. - person Martin; 18.05.2009
comment
Ну и ладно - такое бывает. Я думаю, что вы находитесь на правильном пути, но, возможно, вам нужно использовать другой подход. Подумайте об этом так: в фиксации нет ничего плохого, проблема возникает, когда вы откатываетесь в производственную среду без какого-либо тестирования. - person Neil Trodden; 18.05.2009

arrow_upward
2
arrow_downward

На самом деле SVN лучше, чем NFS. По крайней мере, он обеспечивает атомарно согласованное глобальное представление (т. е. вы не будете синхронизировать половинчатое представление файлов). Я бы возражал против автоматических коммитов при разработке, потому что они не позволяют проводить экспертную оценку, но для административных задач SVN весьма полезен. Мой 2с.

person Remus Rusanu    schedule 17.05.2009

arrow_upward
1
arrow_downward

Это еще один пример Старый ботинок против стеклянной бутылки дебаты. В этом случае монтирование NFS может быть выходом, наша ночная сборка фиксирует изменения версий, и все.

Ваш репозиторий SVN — это то, что вы используете для поддержки версии и сборки своего кода. Если то, что вы делаете, ставит под угрозу это каким-либо образом, ТО НЕ ДЕЛАЙТЕ ЭТОГО.

Если SVN абсолютно, безусловно, лучший способ сделать это, тогда создайте отдельный репозиторий и используйте его, оставьте критический репозиторий в покое.

person Binary Worrier    schedule 17.05.2009

arrow_upward
0
arrow_downward

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

NFS — это круто, но если сервер NFS сломается, у вас будут проблемы. Вы можете попробовать использовать что-то вроде GlusterFS, чтобы иметь несколько копий данных (но не пытайтесь ls каталог glusterfs, так как это O(число файлов)).

Neil Trodden написал отличное замечание по тегам в этой ветке, думаю, это решит Вашу проблему.

person Paweł Polewicz    schedule 17.05.2009
comment
По-моему, в первом предложении пропущено слово. ИМХО, должно быть, но я не вижу смысла ЗАПРЕЩАТЬ автоматические проверки и обновления. - person bortzmeyer; 18.05.2009
comment
Спасибо, что заметили, исправлено. - person Paweł Polewicz; 18.05.2009