Как вы управляете локальными программами?

Как системный администратор, мне часто приходится модифицировать программы для своей компании.

Пример:

Мы используем веб-интерфейс для управления нашим локальным DNS.

После загрузки и извлечения файла tar.gz из Интернета мне необходимо внести некоторые изменения: я добавил соединитель LDAP, изменил некоторые файлы шаблонов, добавил несколько пользовательских нижних колонтитулов / заголовка, добавил дополнительную таблицу в базу данных и т. Д.

Так много модификаций становится трудно отследить.

  • Есть ли способ легко обрабатывать обновления программного обеспечения с таким количеством модификаций?
  • Как сохранить мои модификации при следующем выпуске программного обеспечения?

Еще немного информации:

  • Источники программного обеспечения - это кратные (github, sourceforge и т. д.)
  • Мы более чем один сисадмин
  • системы контроля версий приветствуются
Источник

3 ответа

Решение

Есть ли способ легко обрабатывать обновления программного обеспечения с таким количеством модификаций?

Любые VCS с хорошими возможностями слияния веток. Что выбрать - зависит от множества факторов и привычек

Как сохранить мои модификации при следующем выпуске программного обеспечения?

В мире SVN это называется "Vendor Branches" - ваши изменения в одной ветке, восходящие в другой, вы обновляете ветку вендора и объединяетесь с вашей (подробности читайте в SVN-book или Google)

В DVCS-мире вы можете использовать разные техники

  • ветки, как в SVN
  • патч и патч-менеджмент

Самый простой способ (для меня после некоторого тестирования) - это Mercurial + MQ:

  • мои изменения - это набор MQ-патчей в MQ-очереди, репо - чистый клон апстрима
  • для каждой синхронизации с апстримом я удаляю наложенные патчи из репо, извлекаю источники, повторно применяю патчи (с разрешением конфликтов слияния, если необходимо и сохраняем отредактированные патчи), экспортирую подсказку в неверсированный набор и копирую в конечный пункт назначения
Источник

Используйте контроль версий.

Если для разработки используется текущая система контроля версий, используйте ее.

Если его еще нет, подумайте об использовании git.

Почему мерзавец? Существует столько административных накладных расходов, сколько вам нужно. Вы можете запустить центральный сервер или нет. Тебе решать. SVN является хорошей альтернативой (и широко развернутой), но поддерживать ее может быть сложнее.

Независимо от вашей VCS, вы должны построить базовую структуру каталогов следующим образом:

OPS
|
+ -- Systems
|    |
|    + -- Server2
|         |
|         + -- etc
|              |
|              + -- httpd
|                   |
|                   + httpd.conf
|
+ -- Services
     |
     + -- httpd
          |
          + -- mods
          |
          + -- patches

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

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

cd /etc/httpd/
git init
git add .
git commit -a -m "Initial baseline"

Теперь каждый раз, когда вы меняете файл (ВСЕГДА вы меняете файл, независимо от того, насколько он тривиален). Запустите эту команду:

git commit -a -m "Enabled mod_cgi and debugging for ticket 17789"

Теперь вы храните несколько версий файлов / etc / httpd в каталоге / etc / httpd (в частности, в каталоге /etc/http/.git). Это может выйти из-под контроля с> 10 git-репозиториями, поэтому я рассмотрю запуск git-сервера.

В качестве дополнительного преимущества (настройки сервера) ваши изменения конфигурации теперь могут быть перенесены и извлечены из любого места. Вам больше не нужно будет ssh подключаться к машине для редактирования файлов конфигурации, и вы можете легко запускать diff из любого места. Если вы работаете в большой команде, вы также можете отслеживать и объединять изменения.

Вот несколько статей для начала работы с git:

Git проще, чем вы думаете.

Git в мерзавца

git основной сайт

Источник

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

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

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

Кроме того, это просто усердие и внимание к слияниям, которые не работают. Не мешало бы написать свои собственные регрессионные тесты для всего, к чему вы прикасаетесь, но это на ваше усмотрение.

Источник
Другие вопросы по тегам