Как системному администратору мне часто приходится изменять программы для своей компании.
Пример:
Мы используем веб-интерфейс для управления нашим локальным DNS.
После загрузки и извлечения файла tar.gz из Интернета мне нужно внести некоторые изменения: я добавил соединитель LDAP, изменил некоторые файлы шаблонов, добавил пользовательский нижний колонтитул / заголовок, добавил дополнительную таблицу в базу данных и т. Д.
Так много модификаций трудно отследить.
Еще немного информации:
Используйте контроль версий.
Если для разработки существует текущая система контроля версий, используйте ее.
Если его еще нет, подумайте об использовании 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 к машине, чтобы вручную редактировать файлы конфигурации, и вы можете легко запускать различия из любого места. Если вы работаете в большой команде, вы также можете отслеживать и объединять изменения.
Вот несколько статей, которые помогут вам начать работу с git:
Единственное, что вам нужно, это повторяемый процесс сборки, который берет исходный код из восходящего потока и применяет ваши исправления по порядку, пока вы не получите желаемый результат. (Это, конечно, означает, что вам нужно отслеживать собственные изменения в виде патчей.)
Это может быть что-то столь же простое, как сценарий оболочки, который запускает нужные команды, или вы можете принять более активное участие в этом и создать собственный .rpm / .deb / любой пакет, который выполняет эти шаги за вас. Я обычно выбираю второй путь, так как упаковка имеет много других преимуществ, которые я хотел бы использовать.
Я рекомендую создавать файлы .patch постепенно и сохранять их небольшими по размеру и относящимися к определенным функциям, чтобы уменьшить влияние конфликтов слияния при выпуске новых версий в апстриме. Если вы попытаетесь сделать это с помощью одного гигантского патча крестного отца, который содержит все изменения, внесенные вами в программное обеспечение, он никогда не будет применяться чисто.
Кроме того, это просто усердие и внимание к слияниям, которые не работают. Было бы неплохо написать собственные регрессионные тесты для всего, к чему вы прикоснетесь, но это на ваше усмотрение.
Есть ли способ легко обрабатывать обновления программного обеспечения с таким количеством модификаций?
Любая VCS с хорошими возможностями объединения ветвей. Что выбрать - зависит от множества факторов и привычек
Как сохранить мои модификации при следующем выпуске программного обеспечения?
В мире SVN это называется «Ветви поставщика» - ваши изменения в одной ветке, восходящие в другой, вы обновляете ветку поставщика и объединяете ее в свою (подробности читайте в книге SVN или в Google)
В DVCS-мире можно использовать разные техники
Самый простой способ (для меня, после некоторого тестирования) является ртутным + MQ: