Контроль версий для контроля версий?

Question

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

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

Answer 1

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

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

Самое главное, убедитесь, что документация обновляется - по моему опыту, люди гораздо лучше поддерживают актуальность документации по коду, чем документы администратора. Возможно, это были заинтересованные лица. Одна вещь, которую часто упускают из виду, это если системы конфигурируются в соответствии с стандартной практикой Unix или схожей философией, что подразумевает совокупность знаний о местах, которые могут быть не знакомы программисту OS / X или Windows. с внезапным исправлением сломанного сценария. Не будь снисходительным, убедитесь, что основные предположения о местоположении и взаимозависимости задокументированы.

Answer 2

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

Самое главное, что в этих документах должно быть указано, ПОЧЕМУ вы установили выбранные значения (если не принимать значения по умолчанию).

Во-вторых, в качестве резервной копии те же документы должны быть включены в программное обеспечение для отслеживания ошибок в разделе «Как настроить программное обеспечение для контроля версий?» ошибка. (База данных отслеживания ошибок расположена на другом физическом сервере, верно?)

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

Answer 3

Что не так с использованием одного и того же репозитория контроля версий для ловушек фиксации и других файлов конфигурации? Вот как я справлялся с этим в прошлом, когда отвечал за управление конфигурацией проекта.

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

Answer 4

Если у вас есть сценарии сборки, которые делают это (например, Nant), то вы можете проверять их.