Комментарии 6
НЛО прилетело и опубликовало эту надпись здесь
Существует решение кардинальнее (и «правильнее»): построить процесс сборки приложения, его тестирования и сборки пакетов (которые уже будут распространяться на сервера).
Это вам позволит отвязать весь процесс от система контроля версий и управлять своим ПО с помощью пакетного менеджера вашего дистрибутива. Да и деплой упростится в разы.
Это вам позволит отвязать весь процесс от система контроля версий и управлять своим ПО с помощью пакетного менеджера вашего дистрибутива. Да и деплой упростится в разы.
Спасибо, у нас так и реализовано. Одна проблема — скрипты (SQL, PowerShell, bash, собственные DSL, шаблоны почты и т.п.)
Возникает когда идет не совсем полный релиз: обновление не всех компонентов, частичный патч, ручное исправление, вручную добавлен скрипт (последнее относится к серверам, на которых ведется разработка).
Для «борьбы» с такими ситуациями у нас принято, что установка скриптов на продуктовый сервер производится только из специальной ветки репозитория, чтоб все изменения были закоммичены и можно было увидеть историю. Один из проектов билд-сервер тоже настроен на эту ветку.
Ключевые слова позволяют подменять часть значений автоматически — когда пользователь делает коммит, то локальный файл также обновляется. Таким образом, всегда можно увидеть — из какой версии данный скрипт и (если он поправлен вручную) знать с какой ревизией сравнивать, а не искать по всем ревизиям репозитория.
Возникает когда идет не совсем полный релиз: обновление не всех компонентов, частичный патч, ручное исправление, вручную добавлен скрипт (последнее относится к серверам, на которых ведется разработка).
Для «борьбы» с такими ситуациями у нас принято, что установка скриптов на продуктовый сервер производится только из специальной ветки репозитория, чтоб все изменения были закоммичены и можно было увидеть историю. Один из проектов билд-сервер тоже настроен на эту ветку.
Ключевые слова позволяют подменять часть значений автоматически — когда пользователь делает коммит, то локальный файл также обновляется. Таким образом, всегда можно увидеть — из какой версии данный скрипт и (если он поправлен вручную) знать с какой ревизией сравнивать, а не искать по всем ревизиям репозитория.
Серьёзно…
По понятным причинам вникнуть в проблему снаружи без деталей не получится, но раз у вас уже построен серьёзный процесс выкатывания — то не нужно, наверное, делать исключений. «частичный релиз», «полный релиз» — должны проходить единообразно…
Но это не совет скорее, а мысли вслух, не для обсуждения :-)
По понятным причинам вникнуть в проблему снаружи без деталей не получится, но раз у вас уже построен серьёзный процесс выкатывания — то не нужно, наверное, делать исключений. «частичный релиз», «полный релиз» — должны проходить единообразно…
Но это не совет скорее, а мысли вслух, не для обсуждения :-)
Советую обратить внимание на секцию [auto-props] в настройках клиентского SVNна и на включение [miscellany] enable-auto-props = yes
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Автоматическое добавление keywords к файлам в TortoiseSVN под Windows